[TYPO3-UG Dutch] Afhandeling van poging tot ongeauthoriseerd paginabezoek

[H. Hahn]

Ik ben er inmiddels uit, al heeft het aanmerkelijk langer geduurd dan verwacht.
Ik heb de pagina "Niet gevonden" functioneel in tweeën gesplitst. Voor het gemak zal 
ik de eerste pagina "A" noemen, en de tweede pagina "B".

Ik laat de "Page not found"-handler van Typo3 nu doorsturen naar pagina "A". Deze 
mist nu dus de mogelijkheid om te zien of de bezoeker ingelogd is. (En inmiddels is 
me gebleken dat hij ook geen weet heeft van de taal waarin de bezoeker de pagina 
opvroeg, zodat een op de gebruikelijke wijze vertaalde versie ervan zinloos is. Maar 
die vertaalde versie wel aanwezig zijn, want anders mekkert Typo3 weer dat-ie hem 
niet vinden kan. Dan blijft de zaak in een kringetje ronddraaien!)

Op deze pagina pagina "A" staat een PHP scriptje dat de URL uitleest uit 
$_SERVER['HTTP_REFERER']. Vervolgens vervangt hij in de URL "id=pagina_alias" door 
"origid=pagina_alias", en "taal=n" door "origtaal=n". Verder voegt hij toe 
"id=pagnietgevonden", hetgeen naar de tweede pagina (dus pagina "B") verwijst. 
Vervolgens redirect met naar deze gemanipuleerde URL.

Doordat deze pagina "B" wel bestaat, mekkert Typo3 niet en wordt die pagina keurig 
geladen, met alle gebruikelijke interne variabelen (zoals fe_user etc.) netjes ingevuld.

Op deze pagina draait een PHP-script dat nagaat of:

(a) De oorspronkelijk gevraagde pagina (uit "origid=...") wel bestaat (zo niet, dan 
wordt de tekst "Pagina niet gevonden" weergegeven)
(b) of er voor de gevraagde pagina ingelogd met zijn en zo ja of de bezoeker reeds 
met de juiste rechten heeft (zo niet, dan redirect hij naar de inlogpagina);
(c) Indien de pagina wel bestaat maar niet in de gevraagde taal beschikbaar is, wordt 
een tekst "Sorry, deze pagina is niet beschikbaar in deze taal" weergegeven 
(uiteraard in die betreffende taal).

Merk op dat de functies (a) en (c) niet hetzelfde zijn maar wel dezelfde "fysieke" 
pagina gebruiken. De tekst (evenals de paginakoppen!) wordt gewoon aan de gevonden 
situatie (en aan de taal) aangepast. Voordeel hiervan is dat dit een nog verdere 
redirect overbodig maakt en dus wat sneller is.

En bijkomstig voordeel van deze methode is dat de parameters "origid" (en "origtaal") 
in geval (b) ook aan het inlogscherm worden doorgegeven. Na het inloggen zitten ze 
weliswaar niet meer in de URL, maar ik kan ze in een cookie (automatisch te 
verwijderen door onunload() van inlogbevestigingsscherm!) bewaren, zodat ik na het 
inloggen een link kan weergeven die rechtstreeks naar de oorspronkelijk gevraagde 
pagina leidt. Dat is wel zo "vriendelijk" tegenover de bezoeker.

Er is ook een nadeeltje aan deze werkzijze verbonden, maar dat is heel specifiek voor 
deze website, dus dat laat ik hier maar buiten beschouwing.

H. Hahn

H. Hahn schreef:
> Inmiddels heb ik iets dergelijks geprobeerd, en het lijkt min of meer te 
> werken. Er is echter nog ene probleempje.
> 
> Ik heb het getest met een beveiligde pagina, waarvan geen vertaling 
> beschikbaar is. Dat betekent dat "index.php?id=ledenadmin&taal=0" wel 
> geaccepteerd moet worden, en "index.php?id=ledenadmin&taal=1" niet. En 
> dat gebeurt inderdaad.
> 
> Maar als ik in het geval van "&taal=1" alsnog inlog en dan weer 
> "index.php?id=ledenadmin&taal=1" probeer, zou ik op de pagina "Geen 
> vertaling beschikbaar" moeten komen i.p.v. op "Pagina niet gevonden". 
> Maar dat gebeurt nu juist niet. Het lijkt of ik ineens niet meer 
> ingelogd ben. $TSFE->fe_user->groupData blijkt weer leeg te zijn. Als ik 
> via het menu naar een andere (niet beveiligde) pagina ga, blijk ik 
> ineens weer wel ingelogd te zijn. Ik ben blijkbaar niet uitgelogd 
> geweest, maar het lijkt erop of Typo3 in een veel te vroeg stadium 
> constateert dat de vertaling van de pagina niet beschikbaar is en er 
> daardoor niet an toe komt om de userData in te vullen. Ook in het menu 
> ontbreken op dat moment de beveiligde pagina's.
> 
> Valt hier iets aan te doen? Bijv. de configuratie zo maken dat T3 pas in 
> een later stadium dit soort dingen test, zodat $TSFE->fe_user... wel 
> correct ingevuld is? Of zoiets?
> 
> Ik zou natuurlijk het ingelogd-zijn kunnen testen aan de hand van de 
> cookies (fe_typo_user) en die in de databasetabel fe-sessions opzoeken, 
> maar is dat wel veilig genoeg is? Als er iets gemakkelijk te manipuleren 
> is, zijn dat immers wel cookies.
> 
> Graag advies, waarvoor bij voorbaat dank!
> 
> H. Hahn
> 
> 
> Michiel Roos [netcreators] schreef:
>> Frans Saris schreef:
>>> Hoi Huug,
>>>
>>> zit hier met een soort gelijke vraag/probleem.
>>>
>>> zou graag zien dat gebruikers die de link naar een beveiligde pagina 
>>> hebben
>>> (bijv. opgeslagen in hun favorieten) een inlog pagina krijgen op het 
>>> moment
>>> dat ze de pagina willen openen en hun login sessie nog niet bestaat 
>>> of is
>>> verlopen. Een 404 is hier dus niet op zijn plaats omdat de pagina wel
>>> bestaat maar ze geen toegang hebben.
>>>
>>> Iemand enig idee hoe ik dit het makkelijkste kan opzetten.
>>
>> Beste Frans,
>>
>> De oplossing in 3 eenvoudige stappen.
>>
>> 1). Maak een pagina aan in de root van de site met een naam waarvan je
>> denkt dat die past (maakt niet uit wat). Dit kan zijn: 404 of
>> 'je_moet_inloggen' of 'kannie_vinde' ofzo . . .
>>
>> 2). Vul de pagina met iets zinnigs waar de bezoeker, die er landt, wat
>> aan heeft. Bijvoorbeeld een beschrijving van wat er loos kan zijn (niet
>> ingelogd / pagina kwijt gemaakt), een login box, een sitemap, een
>> klachtenformulier. Je verzint het maar.
>>
>> 3). Open de install tool en zoek de optie 'pageNotFound_handling' op.
>> Vul hier de /404/ of /kannie_vinde/ in.
>>
>> Een voorbeeld (zonder login) vind je hier: http://typo3.nl/404/
>>
>> Met vriendelijke groet,
>>
>>
>> Michiel Roos
>>