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?
Ah zo bedoel je ... echter normaliter word je niet naar een 404 pagina / virtuele pagina geleid, maar gewoon rechtstreeks naar index.php
Dat *is* je 404 error document want alle of de meeste aanroepen zullen virtueel zijn? Je wilt toch vrij zijn in de benaming van je zoekmachine-vriendelijke URLs, deze hebben toch niets van doen met een fysieke directorystructuur? Dat lijkt mij hinken op twee benen.
Echter, alle normale pagina-aanroepen vinden dus plaats via de fallback en NIET via het errordocument. De situatie zoals je die schetst zal dus in werkelijkheid niet plaatsvinden.
Dat snap ik niet? Welke aanroepen zouden dat moeten zijn dan? Je wilt toch niet tig entry points in je applicatie - je wilt een single point of entry: index.php.
Ehhhh... Ik denk dat je 2 dingen door elkaar haalt. Of liever gezegd 3.
We hebben nu 3 manieren behandeld:
- de 404 redirects (alles naar je 404 error pagina index.php omdat je in feite allemaal niet-bestaande pagina's (virtuele URLs) aan het aanroepen bent die alleen hout snijden binnen je applicatie zelf)
- RewriteRules die alles behalve bestaande bestanden en/of directories (over dit laatste verschillen de meningen) doorzet naar je single point of entry index.php
- het alternatief "FallbackResource", die hetzelfde lijkt te werken als vorige variant (heb ik inmiddels getest), maar waarbij je dus geen mod_rewrite en/of FollowSymLinks nodig hebt
Jij hebt in een vorige reply #1 en #3 gecombineerd, maar dat lijkt me niet echt zinnig.
Je hebt je applicatie al zo opgezet dat je applicatie zelf uitrekent welke pagina geserveerd gaat worden, als dan uiteindelijk de uitkomst van die rekensom is dat de opgevraagde pagina niet bestaat (of dat je daar geen toegang toe hebt vanwege rechten of wat dan ook) dan moet de applicatie ook zelf een "page not found" pagina (met bijbehorende headers) serveren.
Ik denk dat een en ander nu door elkaar aan het lopen is.
>> - de 404 redirects (alles naar je 404 error pagina index.php omdat je in feite allemaal niet-bestaande pagina's (virtuele URLs) aan het aanroepen bent die alleen hout snijden binnen je applicatie zelf)
Ik ging dus uit van de variant met FallbackResource die alles naar index.php leidt dat niet bestaat. Kortom alles wat niet bestaat gaat naar index.php. Hier komt dus geen Errordocument aan te pas. Echter, als je een url zou aanroepen die overeenkomt met een directory, zou je een forbidden page kunnen krijgen. Daar zou je dan een Errordocument (403) voor kunnen gebruiken. Maar Errordocument 404 komt er dus helemaal niet aan te pas. Snap je? Dat is dus inderdaad een combinatie van #1 en #3. En zoals ik dus aangaf, zul je zelf nooit zo'n forbidden url aanroepen. Echter, het zou kunnen zijn dat iemand gaat testen of bijv. de directory 'images' aanwezig is. Via Errordocument 403 zou je dan gewoon de homepage kunnen tonen. Waar ik het dus over had, was inderdaad een combi van de fallback en errordoc 403.
chter, als je een url zou aanroepen die overeenkomt met een directory, zou je een forbidden page kunnen krijgen. Daar zou je dan een Errordocument (403) voor kunnen gebruiken.
Zou ik niet doen. Is dubbelzinnig. Je FallbackResource wordt toch getriggerd. Als mensen het leuk vinden om media-folders op te roepen, laat ze. Het staat al in de publieke webdirectory dus je zou deze toch al in mogen zien. Het combineren van 2 methoden is als het hebben van 2 voordeuren, terwijl je liever 1 voordeur (single point of entry) hebt.
>> Zou ik niet doen. Is dubbelzinnig. Je FallbackResource wordt toch getriggerd.
Nope, in dat geval dus niet. Dan krijg je dus letterlijk je error-pagina (403) te zien. De Fallback-functie wordt niet getriggerd omdat het een bestaande directory betreft.
... toch alleen als die ErrorDocument regel in je .htaccess staat.
Als je die weghaalt wordt je FallbackResource document geladen, en dat is wat je wilt. Vervolgens ziet de applicatie dat het pad (REQUEST_URI) waarmee index.php is aangeroepen geen betekenis heeft binnen die applicatie en serveert deze een 404 pagina. See how that works?
Als je echter een URL aanroept die toevallig overeenkomt met de naam van een directory, dan wordt FallbackResource niet meer getriggerd, maar die betreffende directory getoond. Normaliter is je directory afgeschermd wat resulteert in een 403 pagina. Voor deze situatie zou je een dergelijk request via een error document 403 alsnog naar index.php kunnen sturen. Ik zie even niet wat dit met 404 te maken heeft.
Description:
You want a single resource (say, a certain file, like index.php) to handle all requests that come to a particular directory, except those that should go to an existing resource such as an image, or a css file.
Solution:
As of version 2.2.16, you should use the FallbackResource directive for this:
Nee, maar het ging erover als iemand een directory aanroept waarvan je niet wilt dat men weet dat het een directory is. Die aanroep zou je dan (bijv.) via een errordocument-verwijzing kunnen doorsturen naar index.php. Maar kan ook via rewrite uiteraard als je dat zou willen.
Indien iemand een directory aanroept kunnen er verschillende dingen gebeuren, maar volgens mij is het normale gedrag dat ie daar een default document probeert te laden (index.php, index.html, index.htm of wat je ook instelt)?
Dus als je /hennie aanroept dan probeert ie dus /hennie/index.php te serveren, die niet bestaat. --> FallbackResource.
Nee, maar het ging erover als iemand een directory aanroept waarvan je niet wilt dat men weet dat het een directory is
Hopen dat iemand een directorynaam niet raadt is geen goede beveiliging.
Ook zou je je applicatie-code buiten je webdir moeten houden om dit soort "naming collisions" te voorkomen. De enige bestanden die in je publieke webdir zouden moeten staan zijn onder andere, maar mogelijk niet uitsluitend:
- je single point of entry bestand (index.php)
- publiek toegankelijke documenten zoals CSS- en JavaScript-bestanden en afbeeldingen
- standalone scripts
Alles wat niet vrij opvraagbaar zou mogen zijn zou niet in de publieke webdirectory moeten staan, of (ingeval van de standalone scripts) voorzien moeten zijn van controles (gebruikersrechten, IP, whatever).
>> Dus als je /hennie aanroept dan probeert ie dus /hennie/index.php te serveren, die niet bestaat. --> FallbackResource.
Als je indexes zijn geblokkeerd (meestal) krijg je een 403 (probeer maar). En als je met een overkoepelend index-bestand werkt, zul je naar alle waarschijnlijkheid geen index-bestanden in afzonderlijke directories plaatsen omdat dat een totaal andere opzet is.
>> Hopen dat iemand een directorynaam niet raadt is geen goede beveiliging.
Het hoeft ook niet per se beveiliging te zijn, maar ik vind het persoonlijk niet heel mooi. Daarnaast kun je het voorkomen, dus waarom niet?
>> Ook zou je je ... standalone scripts
Klopt. Volledig mee eens. Dat is ook de aanpak die ik zelf hanteer.
