FollowSymLinks
In Plesk heb je de optie om "FollowSymLinks" uit te schakelen.
FollowSymLinks houdt een veiligheidsrisico in, maar ik meen dat je het nodig hebt voor rewriting (mooie URLS). Dus dat je in plaats van www.mijnsite.nl/product.php?id=123 www.mijnsite.nl/product/123 kunt doen. Maar heb je daar per se die FollowSymLinks voor nodig? Of kan het ook zonder? Weet iemand dat?
Kun jij uitleggen waarom het dan eigenlijk in veel tutorials terugkomt? Bijv. hier?
https://websetnet.com/nl/create-seo-friendly-urls-with-your-httaccess-file/
Recentere versies van Apache vereisen FollowSymlinks, of op zijn minst SymlinksIfOwnerMatch, als extra veiligheid. Waarom dit zo gedaan is, geen idee. Ik heb het net getest en de documentatie klopt op dit punt.
Dus als we in plaats van "www.mijnsite.nl/product.php?id=123" werken met "www.mijnsite.nl/product/123" wat doet dat FollowSymLinks dan precies? En op welke manier is SymlinksIfOwnerMatch veiliger?
FollowSymlinks doet wat de naam aangeeft: het staat toe dat Apache symlinks volgt. SymlinksIfOwnerMatch zorgt ervoor dat dat alleen gebeurt wanneer het doel (bestand of directory) dezelfde eigenaar heeft als de bron.
>> dat dat alleen gebeurt wanneer het doel (bestand of directory) dezelfde eigenaar heeft als de bron
Dit snap ik nog niet. Iemand doet dus een request naar mijn website: www.mijnsite.nl/product/123
Wie is dan die eigenaar waar jij het over hebt?
Quote:
The server will only follow symbolic links for which the target
file or directory is owned by the same user id as the link.
file or directory is owned by the same user id as the link.
Een simpel voorbeeld:
Jij hebt /home/ozzie/public_html, en je legt vanuit daar een symlink naar /etc.
Als je nu naar www.example.com/etc gaat krijg je met FollowSymlinks de inhoud van /etc te zien, met SymlinksIfOwnerMatch niet, omdat /etc eigendom is van root, en de link gemaakt is door ozzie. Dus met SymlinksIfOwnerMatch kun je alleen symlinks laten volgen die aan de eis voldoen dat het doel eigendom is van dezelfde user als de link zelf.
Ik leid namelijk ieder request dat geen file is naar index.php. Vandaaruit ga ik dan de juiste pagina renderen. Ik gebruikte in het verleden dit: https://www.adayinthelifeof.nl/2012/01/21/apaches-fallbackresource-your-new-htaccess-command/ Ik zie dat ik dan mod-rewrite niet nodig heb en wellicht ook niet FollowSymLinks?
Gewijzigd op 21/05/2016 21:27:24 door Ozzie PHP
Maar dat fallbackresource lijkt ervoor gemaakt. Dat lijkt me dan de beste oplossing, beter dan de 'normale' werkwijze denk je niet?
Quote:
If you want to do a little bit more exotic stuff, like if you need to use rewriteBase, or maybe have different rewrite conditions, you must stick with the mod_rewrite rules, but most of the time, the fallbackresource will suffice.
Dus als je een slash in je zoekmachinevriendelijke URL zit ben je wss al nat. De meeste SEO URLs die ik ken volgen nog steeds een soort van (directory)structuur.
Soms moet je gewoon dingen kapot laten gaan in plaats van onder het tapijt schuiven of verhullen dat iets niet werkt.
Waar staat dat in die quote?
>> Soms moet je gewoon dingen kapot laten gaan in plaats van onder het tapijt schuiven of verhullen dat iets niet werkt.
Wat bedoel je hiermee?
Kom je niet in de knoei met paden als je /hennie/lala hebt? Gaat het script er dan vanuit dat je vanuit de root werkt of vanuit /hennie? Dit zou je dan uit moeten proberen.
Als ik dat artikel een beetje snel interpreteer staat er zoiets als "als ik een typefout maak dan ... dus doe ik liever iets simpelers". Dat lijkt mij niet zo'n fantastisch uitgangspunt. Zorg gewoon dat je code klopt (gebruik een codebase met een deployment .htaccess-bestand, hoef je het maar 1x goed getypt te hebben en hoef je enkel het bestand te renamen naar .htaccess) en controleer dit ook door 2 tellen door een site heen te klikken.
Als het simpeler kan en dit precies hetzelfde doet juich ik dit toe, de vraag is - is de werking hetzelfde? En zoals aangegeven zijn er "caveats" met die simpelere variant --> mogelijke oversimplificatie die niet altijd werkt? Dan heb ik liever iets dat iets complexer is en dat altijd werkt.
>> Wat bedoel je hiermee?
Niet eindeloos vangnetten proberen aan te brengen voor als X niet doet wat X zou moeten doen. Het kan dan heel lang duren voordat duidelijk is dat X niet naar behoren werkt en de enige remedie is dan nog steeds het repareren van X. Je moet op een gegeven moment ergens van uit kunnen gaan. Als je rewriterules niet werken omdat mod_rewrite niet aanstaat wil je dan overschakelen op een andere techniek? Nee, mod_rewrite is dan in beginsel een noodzakelijke voorwaarde voor correcte operatie van je site. Dit houdt je applicatie ook simpel. Vergelijk het met een site die in principe helemaal zonder JavaScript kan maar ook is ontwikkeld voor gebruik met. Als toegankelijkheid met stip bovenaan staat moet je hier aandacht aan besteden maar anders ga je toch niet investeren in dat soort "fallbacks"? Lijkt mij pure tijdsverspilling en maakt je applicatie nodeloos complex.
Code (php)
1
2
3
2
3
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^ index.php [L,QSA]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^ index.php [L,QSA]
Je kunt in plaats daarvan in .htaccess het volgende zetten:
Code (php)
1
FallbackResource index.php
Toegegeven, als je iets complexer wilt dan is het logisch om te rewriten, en ik gebruik omwille van consistentie ook altijd rewrites, maar zeker bij het gebruik van een frontcontroller oid is de FallbackResource een mooi alternatief.
Een kleine toevoeging trouwens, je hebt wel gelijk over de slashes in paths, Wanneer je bijvoorbeeld naar example.com/test gaat werkt het goed, ga je naar example.com/test/test2 vindt een redirect plaats naar example.com. Door het volgende te doen kun je wel zonder mod_rewrite met een frontcontroller werken en meerdere niveaus diep:
Code (php)
1
ErrorDocument 404 /index.php
Ja, het is ontzettend smerig, maar het werkt wel.
Still, ik zou mod_rewrite wel aanbevelen. De beveiligingsrisico's die genoemd worden met FollowSymlinks zijn gerelateerd aan multiuser systemen, waar je geen controle hebt over wat je gebruikers uitspoken. Sommige "risico's" moet je met een korrel zout nemen.
Gewijzigd op 21/05/2016 23:33:34 door Ben van Velzen
Quote:
Ja, het is ontzettend smerig, maar het werkt wel.
De een noemt dit "cheating", de ander "clever use of game mechanics".
Er zijn dan wel een aantal dingen waar je op moet letten:
- headers, deze zul je expliciet moeten opgeven (200 OK), anders worden al je pagina's echt geserveerd met 404 Not Found;
- deze constructie redirect je ook echt, als je iets POST gaat dat niet werken want je POST data is dan al foetsie; indien je iets wil posten zul je dus een soort niet-SEO-vriendelijke variant moeten hebben waar je naartoe POST bijvoorbeeld http://mysite.local/index.php?path=form&action=processForm ofzo;
Het kan wel. En het is niet eens zo lastig. Bijkomend voordeel is dat je hierbij niet afhankelijk bent van Apache/mod_rewrite. De meeste webservers kennen wel een constructie voor het serveren van een 404 pagina ingeval de opgevraagde pagina niet bestaat. Deze oplossing is dus potentieel breder compatibel dan een oplossing met RewriteRules.
For a price :).
Gewijzigd op 21/05/2016 23:57:30 door Thomas van den Heuvel
Ik kan me dat niet herinneren eigenlijk dat dit gebeurt, maar het is alweer lang geleden dat ik dit getest heb. Waar heb je deze info vandaan?
Als REQUEST_URI niet /test is, redirect dan naar /test.
Ik bezocht de url /test1/test2.
Het resultaat was:
Redirect naar /
gevolgd door redirect naar /test.
Wanneer ik naar /test1 ging werd direct een redirect gedaan naar /test.
Dus het lijkt gerelateerd te zijn aan het niveau waar je in zit. Ik ben nu te lui om naar de apache sourcecode te kijken, maar het is ongetwijfeld terug te vinden. Kijk hier eens naar: https://github.com/apache/httpd/blob/trunk/modules/mappers/mod_dir.c