een bestand buiten de root folder zetten

<?php
$huidige_directory = __DIR__;
$hogere_directory  = realpath(__DIR__ . '/..');
?>

Dan moet ik het zeg maar zo doen:

<?php
$buitenroot = realpath($_SERVER[ 'DOCUMENT_ROOT' ] . '/..');
?>

maar dan pakt hij inderdaad precies de directory die ik nodig heb! Super, dank je wel!!

Mits je daar schrijfrechten hebt :).

Hmmm. Bij mijn eigen host heb ik die dus doorgaans zal het niet uitmaken. Maar zo niet, kun je dat dan niet gewoon in het script zelf instellen? chmod naar 777 en na het opslaan van het bestand weer terug naar waar het eerst op stond?

als je een stukje wilt fietsen, pak je een willekeurige fiets.
als de fiets op slot staat, haal je het slot eraf.
Na het fietsen zet je hem weer vast.

Is analoog aan "doe maar chmod 777 als je geen rechten hebt."
Geen rechten = geen sleutel, dus dan kun je hem ook niet even opengooeien

[size=xsmall]Toevoeging op 27/01/2017 16:20:50:[/size]

is trouwens dirname() niet een kortere versie voor realpath en dan /..

[size=xsmall]Toevoeging op 27/01/2017 16:23:35:[/size]

zorg voor de schrijfrechten dat de user waaronder het proces draait dat moet schrijven, de schrijfrechten heeft.

Bijvoorkeur door te zorgen dat dat op basis van "owner" of "group" is. Dus dat de rechten 770 genoeg zijn.

zet je de 3e waarde ook op 7, dan zou het zo maar kunnen dat iedere user op de server in die map kan lezen en schrijven.

Wanneer je niets kan/mag in de directory boven de webroot dan kun je daar ook geen bestanden neerzetten. De directory zal in eerste instantie bepalen wat mogelijk is.

Ok, dat is dan wel een dingetje om rekening mee te houden. Bij mijn host heb ik toegang tot die directory en is het geen probleem. Maar mocht ik het script eens elders moeten gebruiken dan moet ik dat dus wel eerst testen voor ik het bestand buiten de root folder probeer neer te kwakken, en het anders ergens anders neerzetten.

als je een stukje wilt fietsen, pak je een willekeurige fiets.
als de fiets op slot staat, haal je het slot eraf.
Na het fietsen zet je hem weer vast.

Tja... maar, als die fiets in je eigen achtertuin staat en je ervoor betaald hebt, dan is dat toch niet zo'n raar idee? Hoe moet je anders ooit een fietstochtje maken?

Als in je achtertuin de fiets van een vriend staat, heb je de sleutel niet.

Als de map niet van het proces is, dan kun je er nog niet in.

Vaak is de map van de gebruiker "website_nl"

Het php process kan draaien onder de user "apache", "www" of iets dergelijks. In de map "public_html" (als dat de documentroot is) kan het process dan lezen. (meeste hosting partijen richten dat zo in :-) )

maar de map die naast public_html staat, laten we die "bestanden" noemen:
wie maakt die aan.
Grote kans dat jij dat doet met je ftp programma. Dan wordt die map dus van de user "website_nl". Je kunt er niet zondermeer vanuit gaan dat "apache" dan ook daar mag kijken.

De simpele benadering zou zijn om de map met chmod 777 door de ftp user open te zetten.

Beter is het om dan in elk geval nog te zorgen dat de groupsrechten (de 2e 7) voldoende zijn.
Vraag is alleen of jij dat zelf kunt inregelen, of dat de site beheerder dat moet doen. Niet elke user kan namelijk zomaar bepalen van welke user/group een bestand of map is.

Draait het process onder de user website_nl, dan is het probleem een stuk kleiner.

Hmm, ik snap wat je bedoelt. Als ik het script dus ooit op een andere server wil installeren moet ik er rekening mee houden dat ik via de ftp de rechten moet aanpassen (wat op zich ook niet uitmaakt) of het bestand in een andere map zetten waar het script wel rechten heeft.

Het gaat overigens om een bestand met alle inloggegevens van zowel de database als smtp. Misschien maakt het ook wel helemaal niet zoveel uit als het gewoon in een map binnen de rootfolder zet. Wordpress en Drupal doen dat ook niet. Hoe veilig is het om dat soort bestanden op de server te bewaren?

zelf zet ik alles wat niet aangeroepen hoeft te worden door een browser buiten de document root.

in de document root staan bij mij alleen
index.php
map css/ met de css bestanden
map js/
map img/ met afbeeldingen tbv de layout. (dus niet geuploade door applicaties, bijvoorbeeld van te verhuren objecten)


Buiten de document root staan bij mij mappen met inderdaad de config files,
maar ook mappen met models, controllers en views
algemene classes etc.

vanuit index.php wordt iets aangeroepen buiten de document root en de betreffende controller zorgt voor de rest.

Het voorkomt in elk geval dat scripts vanuit een browser aangeroepen worden. Hoewel de meeste scripts weinig doen als rechtstreeks aangesproken (als er alleen een class in staat, dan wordt er niets zo maar uitgevoerd), maar als het niet hoeft, dan mag het wat mij betreft ook niet.

Terug naar jouw config:
moet er geschreven worden, of is lezen genoeg. Dat scheelt wel wat.

In elk geval zou ik gaan voor een script.
dus niet een tekst bestand met een leesbare tekst (zo iets als een php.ini file bedoel ik)
Dat is namelijk leesbaar als iemand de file aanroept in de browser.

een config.php levert hopelijk gewoon een blanco response.

Verder kan een .htaccess bestand met Deny From All erin helpen. (dat dus alleen voor de browser geldt en niet voor php zelf)