.inc bestand niet zichtbaar maken

[Slagroom]

Hallo,

Kan ik mbv een .htaccess bestand een *.inc bestand beveiligen dat men niet de inhoudt van hat bestand zien?

[D2k]

je kan um ook gewoon .php noemen
als het over je database pass ding gaat dan


dan is de inhoud zeker niet opvraagbaar

[Verwijderd]

in je htacces bestand kun je natuurlijk ook een .inc bestand als een .php bestand laten parsen...

AddType application/x-httpd-php .inc

[Slagroom]

weet ik allemaal niet zo nietjes... vindt ik... maar is het niet anders mogelijk?

[D2k]

Op vrijdag 22 februari 2002 10:46 schreef Monstar.nl het volgende:
weet ik allemaal niet zo nietjes... vindt ik... maar is het niet anders mogelijk?

http://www.bruce-hamilton.com/tutorials/password.shtml

en niet netjes??
"beauty is in the eye of the beholder"

[TheDane]

je zou 't bestand buiten de webtree kunnen plaatsen

[HGM]

best is natuurlijk om het buiten de webroot de plaatsen, en ook de .php toe te voegen. Veel veiliger dan dat kan IMO niet.

Een .htaccess is een slecht idee, denk oa aan: verhuizing, fouten in httpd.conf etc.

_{Edit: net te laat}

[eborn]

Maar je kunt i.d.d. wel iets in je httpd.conf instellen. Volgens mij gebeurt dat in een <Files> section. Het wordt al standaard gebruikt zodat je bestanden die beginnen met .ht niet op kunt vragen (dacht ik).

[Slagroom]

Ik heb geen toegang tot buiten de tree...

[Glimi]

code:

<Files ~ "^\.ht">
    Order allow,deny
    Deny from all
</Files>

Standaard in je httpd.conf, moet genoeg doen bij apache.
Dus een vieze oplossing kan zijn om ze .ht.naam.inc te noemen
Mooier is om in apache een fijne <Files> desc te maken die ervoor zorgt dat .inc files niet geparsed worden

[Slagroom]

Of zo?

<Files ~ ".inc^\">
Order allow,deny
Deny from all
</Files>

[HGM]

Daarom moet je dit dus niet zo oplossen, mocht je nu ooit verhuizen of de config zou aangepast worden dan kan iedereen ze zo benaderen.

Ookal denk je nu dat je dat nooit zult vergeten, maar ... _{vergeten is menselijk}

[Slagroom]

dus gewoon .php3?

[D2k]

Op vrijdag 22 februari 2002 10:43 schreef D2k het volgende:
je kan um ook gewoon .php noemen
als het over je database pass ding gaat dan


dan is de inhoud zeker niet opvraagbaar

[kvdveer]

rm -rf /
Is 'ie ook niet meer zichtbaar...

In je .htaccess hoor je dit soort dingen doen, maar doorgaans geef ik mijn includebestanden gewoon de extensie php.
Of zoals phpmyadmin het doet: *.inc.php
Andere optie die ik vrijwel altijd gebruik: includes in een apparte dir, met daarin een hele beperkte htaccess.

[axis]

zou ze ook .php noemen.. of ja, in mijn geval .asp.. doe ik tenminste wel altijd met mijn includes..

[paulh]

Bij php.net adviseren ze ook gewoon er .php of .php3 achter te plakken. Het stoort mij totaal niet.

[Verwijderd]

of chmod meschien ? weet niet of het werkt nooit getest

[Verwijderd]

je moet wel oppassen met het adden van .php, als iemand die pagina heeel erg veel word aangevraagd, want dan kan de server load behoorlijk oplopen.

ik had eens een klant die zo leuk was al zijn html pagina's naar .php te gaan noemen, en het gevolg was dat hij met 200 bezoekers per dag de server in de spits tijd af en toe omver trok, omdat alles door php geparsed moest worden.

[GraasGast]

ik noem die dingen vaak gewoon blaat.inc.php

[Glimi]

Op vrijdag 22 februari 2002 21:13 schreef de-emotie-man het volgende:
of chmod meschien ? weet niet of het werkt nooit getest

Denk niet dat dat gaat werken Het .inc bestand moet world readable zijn (of in ieder geval readable voor de user waar apache/de webserver onder draait). Als iemand het dan wil downen via apache, tja dan kan dat he

[brammetje]

Als je ze niet buiten de webtree kan zetten, noem ze dan *.inc.php en gooi er een .htaccess voor. Als er dan eens wat gebeurt met de apache-conf (shit, hij parsed php niet meer) dan is het afgeschermt.

[Glimi]

Op vrijdag 22 februari 2002 22:41 schreef brammetje het volgende:
Als je ze niet buiten de webtree kan zetten, noem ze dan *.inc.php en gooi er een .htaccess voor. Als er dan eens wat gebeurt met de apache-conf (shit, hij parsed php niet meer) dan is het afgeschermt.

Mijn vertrouwen in apache is groter dan in PHP, maar dat is persoonlijk.
Concluderend kunnen we toch wel zeggen dat het niet echt veiliger wordt dan de oplossing die brammetje hier geeft. Of het bestand moet versleuteld worden, maar dan moet de key ook weer ergens staan (readable voor de apache user), dus dat schiet ook niet op

[HGM]

Op vrijdag 22 februari 2002 23:55 schreef Glimi het volgende:

[..]

Of het bestand moet versleuteld worden, maar dan moet de key ook weer ergens staan (readable voor de apache user), dus dat schiet ook niet op

Zend-encoder is dus de beste oplossing