FollowSymLinks
Uiteindelijk stel ik altijd als eis dat anderen ook met de code moeten kunnen werken. Rewrite rules worden door iedereen begrepen, praktisch niemand kent de alternatieven. Als je doel is "ik wil FollowSymlinks niet aan hebben", maar tegelijk heb je geen andere gebruikers op je server, waar maak je je dan eigenlijk druk om? Zoals gezegd, de "risks" die bij FollowSymlinks worden genoemd gelden wanneer je geen controle hebt over wat je gebruikers uitspoken, i.e. shared hosting. Er zijn geen verdere risico's, want ik kan me niet voostellen dat je zoiets stoms doet als ln -s /etc.
Wat bedoel je hier mee ... ik volg je even niet (het is al laat).
Quote:
De truc met het errordoc is nieuw, maar als het werkt wel een mooie.
Nou nee, het is min of meer een oneigenlijk gebruik van een voorziening. En ook eentje met haken en ogen zoals @Ben hierboven en ik al eerder aangaven. Maar als je niets anders hebt (je gebruikt geen Apache) dan zou je dit kunnen overwegen. Aan de andere kant, waarom had je dan gekozen voor een technische oplossing zonder Apache wanneer dit toch verdomd handig was geweest?
Wat @Ben eerder zei over nette URL's in zoekpagina's:
Quote:
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 optiek van zoekmachines is dit inderdaad niet erg nuttig maar uit oogpunt van werk kan het aanhouden van één schrijfwijze van URLs toch makkelijker zijn (en tevens heb je hiermee uniformiteit). En mogelijk heb je ook grijze gebieden. Denk bijvoorbeeld aan doorzoekbare/sorteerbare/filterbare portfolio-pagina's.
Deze luxe (enkelvoudige schrijfwijze) heb je niet bij een oplossing middels de "404 redirects" - het POSTen van data zal hoe dan ook via een ander pad moeten verlopen (pun intended), bijvoorbeeld via een andere schrijfwijze van een URL die rechtstreeks aan index.php refereert. Bij deze oplossing blijf je dus een soort duaal stelsel (wel en niet zoekmachinevriendelijke URLs) in stand houden. Dit heeft ook zekere voordelen maar het is wederom extra werk.
Ik heb het idee dat jij (Ozzie) de laatste tijd nogal zoekende bent op allerlei uiteenlopende gebieden waarbij je (correct me if I'm wrong) een soort "beste antwoord" zoekt. Het feit dat er meestal meerdere oplossingen bestaan (die ook min of meer hun bestaansrecht bewijzen? als er geen behoefte zou zijn aan verschillende insteken zouden deze op den duur verdwijnen?) wil mogelijk zeggen dat er geen "beste oplossing" is. Er zijn enkel keuzes die je kunt maken en implicaties die deze keuzes hebben. Ik denk dat het zinniger is als je eerst een soort van pakket van eisen hebt "dit is wat ik wil dat iets moet kunnen" en dat je vervolgens kijkt wat er beschikbaar is en wat je hier (niet) mee kunt doen. Indien je de implicaties goed overziet kun je met enige zekerheid een juiste keuze maken. Dat is soms het best haalbare. Of je probeert meerdere alternatieven uit en kijkt wat voor jou het beste werkt.
Maar dit is neem ik aan alleen het geval wanneer je post naar een 403 pagina zou leiden toch? Als je post naar een normale pagina is dit toch niet van toepassing?
>> Deze luxe (enkelvoudige schrijfwijze) heb je niet bij een oplossing middels de "404 redirects" - het POSTen van data zal hoe dan ook via een ander pad moeten verlopen (pun intended)
Ik snap dus nog steeds even niet wat dat errordocument te maken heeft met het posten :-s
Anyhow ... ik ben het wel er mee eens dat het een oneigenlijk gebruik is van een errordocument, dus misschien is de 'normale' oplossing dan toch wel beter.
Gewijzigd op 22/05/2016 15:31:41 door Ozzie PHP
(Dit even afgezien van of het wel of niet een chique manier is.)
X bestaat niet, je wordt geredirect naar 404 pagina Y.
Op pagina Y is $_POST leeg.
Met navigatie via de error document wordt je altijd geredirect... Of in ieder geval dit gedraagt zich als een redirect, wat er ook onder water moge gebeuren.
Gewijzigd op 22/05/2016 21:18:00 door Thomas van den Heuvel
Het redirecten zou alleen plaatsvinden als de url overeenkomt met een BESTAANDE map. Dat zou een 403 error opleveren die je naar index.php kunt doorsturen. 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.
Gewijzigd op 22/05/2016 22:35:48 door Ozzie PHP
Quote:
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.
Quote:
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.
Gewijzigd op 22/05/2016 23:45:45 door Thomas van den Heuvel
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.
Quote:
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.
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.
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?
FallbackResource stuurt alles naar index.php
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.
Quote:
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:
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:
Daar komt toch geen ErrorDocument aan te pas?
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.
Dus als je /hennie aanroept dan probeert ie dus /hennie/index.php te serveren, die niet bestaat. --> FallbackResource.
Quote:
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).
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.
Gewijzigd op 24/05/2016 00:34:27 door Ozzie PHP