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=123www.mijnsite.nl/product/123 kunt doen. Maar heb je daar per se die FollowSymLinks voor nodig? Of kan het ook zonder? Weet iemand dat?
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?
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.
Thomas, je hebt opzich een punt, maar wat hier een fallback genoemd wordt is daadwerkelijk in te zetten als een alternatief voor
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^ index.php [L,QSA]
Je kunt in plaats daarvan in .htaccess het volgende zetten:
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:
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.
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.
Klopt, en opzich is het ook geen ramp dat je voor je forms geen "nette" urls kan gebruiken. Het zijn urls die een zoekmachine toch niet bezoekt. Net als zoekpagina's trouwens. Ik kan altijd lachen om de bochten waarin men zich wringt om zoekpagina's van nette urls te voorzien, terwijl het helemaal geen nut heeft.
Uit een kijkje in het console tijdens het testen. Ik had de volgende opzet:
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.
