een bestand buiten de root folder zetten
Ik moet dus een manier vinden om te bepalen wat de rootfolder van de website is, en daar één directory boven gaan zitten.
Als ik $_SERVER[ 'DOCUMENT_ROOT' ] gebruik krijg ik zoiets:
/home000/sub000/sc00000-AAAA/domeinnaam.nl
domeinnaam.nl is de naam van de map waar de website instaat. In dit geval is de naam van de map daarboven dus sc00000-AAAA, de map die ik moet hebben. Maar hoe specificeer ik dat in php?
Gewijzigd op 27/01/2017 15:19:59 door Marlies Maalderink
maar dan pakt hij inderdaad precies de directory die ik nodig heb! Super, dank je wel!!
Mits je daar schrijfrechten hebt :).
Gewijzigd op 27/01/2017 16:03:22 door Marlies Maalderink
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
Toevoeging op 27/01/2017 16:20:50:
is trouwens dirname() niet een kortere versie voor realpath en dan /..
Toevoeging op 27/01/2017 16:23:35:
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.
Gewijzigd op 27/01/2017 16:24:20 door Ivo P
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.
Quote:
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.
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 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.
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?
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)
Dat iemand het bestand in de browser aanroept lijkt me idd niet zo erg, want dat levert gewoon een wit scherm op. Maar ik weet niet of er andere manieren zijn om toch bij de code te komen.
Op zich maakt het niet zoveel uit, wat ik al zei, als ik het script wil installeren moet ik sowieso FTP toegang hebben om de bestanden te kunnen uploaden dus kan ik ook de rechten van de benodigde map veranderen... Maar het is dan idd wel prettig om het toch buiten de root folder te zetten, dus hou ik het maar zo.
Marlies Maalderink op 27/01/2017 17:35:57:
Dat iemand het bestand in de browser aanroept lijkt me idd niet zo erg, want dat levert gewoon een wit scherm op.
Je kunt daarvoor in settings.php een controle opnemen op een constante die ergens anders wordt gedefinieerd, bijvoorbeeld in het PHP-bestand dat settings.php met include of require insluit:
Code (php)
Inclusief een 404-fout, zodat het voor buitenstaanders lijkt dat het bestand niet eens bestaat.
Een techniek die ik wel eens gebruik als ik niet kan schrijven buiten de webroot, is in .htaccess de toegang tot alle config.* weigeren — dus tot config.ini, config.php, config.inc, config.yml, enzovoort:
Misschien een domme vraag, maar als je via .htaccess alle toegang weigert tot config.*, kun je het bestand dan nog wel includen in een ander bestand?
Marlies Maalderink op 28/01/2017 09:41:37:
Misschien een domme vraag, maar als je via .htaccess alle toegang weigert tot config.*, kun je het bestand dan nog wel includen in een ander bestand?
Ja want includen gaat intern via de filesystem en niet via het http protocol.
Als een gebruiker een pagina (is gelijk aan een bestand) opvraagt via de webbrowser dan zal de webserver (bijv, apache) onder andere kijken naar de .htaccess bestanden en bepalen of de gebruiker deze pagina wel mag zien.
Maar als een php script gestart wordt door apache dan is dit een proces dat draait op de achtergrond van de webserver. Dit proces heeft vervolgens toegang tot alle bestanden waarvoor het gemachtigd is. Ik praat dan over de toegangsrechten van het filesystem. ,htaccess bestanden hebben daar niets mee te maken.
Duidelijk, dank voor de uitleg, ik kan weer verder :)