[php] Session, Post-form, no-cookie

[ajakkes]

Het zal wel een heel simpel antwoord zijn. Maar ben al een tijdje aan het zoeken en kan het antwoord niet vinden.

Ik heb een formulier
Verzend de data via

PHP:

<form method="post" action="<?php print $_SERVER['PHP_SELF']."?page=mynewpage&".SID;?>

De url voor de volgende pagina is:
index.php?page=mynewpage&PHPSESSID=gqm0t9i414vpgqkvl13cljpc12

en de session_id() is e0efup52j0gsto5o91n8gn78o6

De vraag is dus hoe stuur ik bij een post formulier netjes het SID mee?

[GlowMouse]

waarom moet je SID zelf meesturen, en waarom verandert die opeens?

[Voor 32% gewijzigd door GlowMouse op 19-08-2010 13:44]

[CRiMiNaL]

Ik begrijp niet wat je wilt doen, maar als ik je vraag begrijp dan lost je dat als volgt op:

PHP:

<form method="post" action="<?php print $_SERVER['PHP_SELF']."?page=mynewpage&PHPSESSID=".session_id();?>">

[Manuel]

1. Gebruik geen PHP_SELF, vatbaar voor XSS
2. Je SID wordt pas geset indien het sessionID incorrect is of als er geen cookie is geset met het sessionID maar de sessie wel is gestart. Meer informatie: PHP: Predefined Constants - Manual

Verder vraag ik mij ook af waarom je het SID wil meesturen aangezien dit normaliter via cookies gebeurd.

[Voor 4% gewijzigd door Manuel op 19-08-2010 13:50. Reden: * typo]

[RobIII]

Manuel schreef op donderdag 19 augustus 2010 @ 13:47:
1. Gebruik geen PHP_SELF, vatbaar voor XSS
2. Je constant SID wordt pas geset indien de sessionID incorrect is of als er geen cookie is geset met het sessionID. Meer informatie: PHP: Predefined Constants - Manual

Verder vraag ik mij ook af waarom je het SID wil meesturen aangezien dit normaliter via cookies gebeurd.

^^ Wat hij zegt. Een sessie_id wil je helemaal niet in je url hebben.

[Voor 87% gewijzigd door RobIII op 19-08-2010 13:52]

[ajakkes]

Omdat cookies uitstaan veranderd de session_id() bij elke nieuwe pageload. Deze wordt namelijk opgeslagen in een cookie.
Om die reden zal je de SID moeten meesturen met de url, heb ik begrepen.
Het meesturen van de SID lukt. Zoals je kan zien aan de url van de volgende pagina

index.php?page=mynewpage&PHPSESSID=gqm0t9i414vpgqkvl13cljpc12

achter PHPSESSID staat dezelfde code als de session_id() waarde op de vorige pagina.

Als ik de session_id() echter opvraag in de pagina zelf is hij veranderd:

print session_id(); geeft e0efup52j0gsto5o91n8gn78o6

Ik wil dus de session in stand houden icm uitgeschakelde cookies en een post formulier.

[Currahee]

// Spuit 11

[Voor 97% gewijzigd door Currahee op 19-08-2010 13:53]

[GlowMouse]

ajakkes schreef op donderdag 19 augustus 2010 @ 13:50:
Omdat cookies uitstaan

Als je dat niet kunt beïnvloeden, dan kun je php beter zelf het doorsturen laten afhandelen want dan kun je het nergens vergeten, zie http://www.php.net/manual/en/session.idpassing.php

[CRiMiNaL]

RobIII schreef op donderdag 19 augustus 2010 @ 13:47:
Wat is SID
Bedoel je niet $SID ? En waarmee is SID gevuld?

[...]

^^ Wat hij zegt. Een sessie_id wil je helemaal niet in je url hebben.

Netjes is anders, dat ben ik met je eens, maar vanuit veiligheid opzicht maakt het niet zoveel uit of je sessie_id nu in de request url staat (geen gebruik van cookies) of in de request headers (wel gebruik van cookies).

TS geef in topic titel aan dat het hier gaat om geen cookies, dan zal je toch op een manier de identifier van je huidige sessie moeten controleren.

[RobIII]

CRiMiNaL schreef op donderdag 19 augustus 2010 @ 13:53:
Netjes is anders, dat ben ik met je eens, maar vanuit veiligheid opzicht maakt het niet zoveel uit of je sessie_id nu in de request url staat (geen gebruik van cookies) of in de request headers (wel gebruik van cookies).

Het komt vaak voor dat iemand een url copy/paste in een forum oid en dan heb je een session_id erin zitten dat je niet wil hebben. Vervolgens maak je weer kans dat zoekmachines allerlei pagina's met die session_id gaan lopen indexeren (en die session_id ook weer lekker in de zoekresultaten opnemen etc). Het is gewoon gevaarlijk; zeker als je een beetje naïef met sessies omgaat.

CRiMiNaL schreef op donderdag 19 augustus 2010 @ 13:53:
TS geef in topic titel aan dat het hier gaat om geen cookies, dan zal je toch op een manier de identifier van je huidige sessie moeten controleren.

Ja, ik dat had ik even gemist Ik zag ook net dit pas.

[Voor 60% gewijzigd door RobIII op 19-08-2010 13:57]

[HuHu]

ajakkes schreef op donderdag 19 augustus 2010 @ 13:50:
Omdat cookies uitstaan veranderd de session_id() bij elke nieuwe pageload. Deze wordt namelijk opgeslagen in een cookie.
Om die reden zal je de SID moeten meesturen met de url, heb ik begrepen.
Het meesturen van de SID lukt. Zoals je kan zien aan de url van de volgende pagina

index.php?page=mynewpage&PHPSESSID=gqm0t9i414vpgqkvl13cljpc12

achter PHPSESSID staat dezelfde code als de session_id() waarde op de vorige pagina.

Als ik de session_id() echter opvraag in de pagina zelf is hij veranderd:

print session_id(); geeft e0efup52j0gsto5o91n8gn78o6

Ik wil dus de session in stand houden icm uitgeschakelde cookies en een post formulier.

Dan moet je bij het opstarten van de sessie zelf wat regelen, want automatisch de SID uit de GET halen in plaats van de COOKIE gaat niet (kan op zich wel, zie GlowMouse hierboven). Dat gaat dan ongeveer zo:

PHP:

session_start();

if (!isset($_COOKIE[session_name()] && isset($_GET[session_name()])) {
  session_id($_GET[session_name()]);
}

[ajakkes]

Daar waar ik lees over het gebruik van session lees ik dat het mogelijk is om sessions ook in stand te houden als er geen cookies beschikbaar zijn.

Mijn uiteindelijke doel is het in stand houden van de sessie als er geen cookies zijn.

Als er andere methodes zijn hoor ik dat graag. Ook mijn voorkeur gaat naar geen session_id() in de url. Maar ik heb begrepen dat ik hem via get of post moet versturen om het in stand te houden.

SID is een methode/functie die gelijkstaat aan print "PHPSESSID=".session_id()
Deze is ingebouwd in php zelf. Ik heb het niet bedacht. Hij is gemaakt om het makkelijk te maken de session_id() door te geven via get/post.

GlowMouse op de pagina die je geeft staat:
<?php echo htmlspecialchars(SID); ?> in plaats van <?php print SID; ?> misschien zit het hem daarin.

[ajakkes]

Ik ga je oplossing proberen HuHu.

Wel raar dat dit niet genoemd wordt op de pagina:
http://www.php.net/manual/en/session.idpassing.php

Het voorbeeld daar slaat ook de SID op in de url. Je zou verwachten dat jou code dan ook in het voorbeeld zou moeten staan.

Ben blij dat het antwoord niet heel simpel was.

Houden jullie geen rekening met gebruikers met cookies disabled?

[HuHu]

Ik vraag me trouwens af of het tegenwoordig nog wel noodzakelijk is om rekening te houden met mensen die het gebruik van cookies uit hebben gezet. Volgens mij komt dat echt nooit meer voor, dus ik ben eerlijk gezegd van mening dat het niet nodig is om daar rekening mee te houden.

[HuHu]

ajakkes schreef op donderdag 19 augustus 2010 @ 14:07:
Ik ga je oplossing proberen HuHu.

Wel raar dat dit niet genoemd wordt op de pagina:
http://www.php.net/manual/en/session.idpassing.php

Het voorbeeld daar slaat ook de SID op in de url. Je zou verwachten dat jou code dan ook in het voorbeeld zou moeten staan.

Ben blij dat het antwoord niet heel simpel was.

Houden jullie geen rekening met gebruikers met cookies disabled?

PHP zou het automatisch moeten kunnen, maar als je de comments leest zie je wel dit staan:

When you generate URLs yourself using the SID variable, it must come first in the URL parameter list.

Dat is bij jou niet het geval, de parameter page komt eerst.

[ajakkes]

Ah, dan zal ik de SID verplaatsen naar voren/eerder toevoegen aan de url.

Zal de volgende keer nog iets verder moeten kijken. Tnx HuHu.

En blijkbaar moet ik de [PHP_SELF] ook nog nakijken. Kan ik natuurlijk makkelijk vervangen in de echte url.

offtopic:
BTW. trek de champagne maar open. Dit is m'n 51ste post.

[Avalaxy]

Is het niet handiger om gewoon zelf een stel functies te schrijven voor session_set_save_handler() en daarmee de sessions op te slaan in een database waarna je ze op een andere pagina weer ophaalt? Lijkt me heel wat veiliger dan ze passen in de URL en ophalen met GET. Bijkomend voordeel is dat je sessions niet via het File System opgevraagd kunnen worden in het geval van shared hosting.

ajakkes schreef op donderdag 19 augustus 2010 @ 14:17:
En blijkbaar moet ik de [PHP_SELF] ook nog nakijken. Kan ik natuurlijk makkelijk vervangen in de echte url.

Absolute URL is niet handig met het oog op portability.

[Voor 23% gewijzigd door Avalaxy op 19-08-2010 14:25]

[HuHu]

Avalaxy schreef op donderdag 19 augustus 2010 @ 14:24:
Is het niet handiger om gewoon zelf een stel functies te schrijven voor session_set_save_handler() en daarmee de sessions op te slaan in een database waarna je ze op een andere pagina weer ophaalt? Lijkt me heel wat veiliger dan ze passen in de URL en ophalen met GET. Bijkomend voordeel is dat je sessions niet via het File System opgevraagd kunnen worden in het geval van shared hosting.

Volgens mij haal jij het sessie-id en de daadwerkelijke inhoud van de sessie door elkaar. Of de sessie nu met of zonder eigen save-handler wordt gebruikt, dat heeft geen enkele invloed op het doorgeven van het ID via cookie of url.

Verder heeft een goede hoster z'n sessies gescheiden.

[...]


Absolute URL is niet handig met het oog op portability.

Het is zelfs onmogelijk als je de standaard PHP functionaliteit gebruikt:

Non-relative URLs are assumed to point to external sites and hence don't append the SID, as it would be a security risk to leak the SID to a different server.

[ajakkes]

Ik was van plan om ['php_self'] te vervangen door index.php. Dit is dus gewoon een relative path.
Maar ik begrijp van de aangegeven pagina dat ['REQUEST_URI'] ook veilig zou moeten zijn.
(Getest met het voorbeeld op de site)


Het doorgeven van de SID werkt nu. Kan ik hem echter ook gewoon via de post verzenden?
Moet ik dan
<input type="hidden" name="PHPSESSID" value="<?php print session_id(); ?>">
doen of kan ik met SID werken?
En kan ik bij een gewone url de "index?".SID vervangen door een manier via post?
Post blijft namelijk netter dan get.

[HuHu]

Ik neem aan dat je het verschil tussen POST en GET weet, weet hoe een browser een pagina opvraagt en daarmee dus ook zelf je vraag kunt beantwoorden?

spoiler:

Nee, tenzij formulier. Maar dan nog, lekker boeiend voor die 0,00001 user zonder cookies.

[ajakkes]

Ik weet het verschil tussen post en get. Ik heb echter begrepen dat je user input nooit mag vertrouwen. Ook als het om post data gaat.

Om die reden heb ik het vermoeden dat het mogelijk is post data te verzenden zonder een submit knop te gebruiken.

Maar inderdaad is het voor die kleine groep gebruikers misschien wel handig implementatie over te slaan. Vandaar dat er ook zo weinig over te vinden is.

Ik loop nu alweer tegen problemen aan bij een ander formulier dat ik wel via get verstuur. Ik doe iets verkeerd maar ik heb geen zin het op te lossen. Ze gaan maar koekjes slikken.

[Patriot]

Om die reden heb ik het vermoeden dat het mogelijk is post data te verzenden zonder een submit knop te gebruiken.

Euh.. wat maakt dat uit?

[ajakkes]

Als post data verzonden kan worden zonder een submit knop moet het toch ook mogelijk zijn om de session_id() te verzenden zonder submit via post.

Indeed omslachtig. (not gonna happen).

[CodeCaster]

ajakkes schreef op donderdag 19 augustus 2010 @ 15:38:
Als post data verzonden kan worden zonder een submit knop moet het toch ook mogelijk zijn om de session_id() te verzenden zonder submit via post.

Indeed omslachtig. (not gonna happen).

Ja hoor, je kunt met javascript alle links zodanig bewerken dat ze je sessie-id en een link-id meeposten bij iedere klik. Je kunt ook gewoon meteen in ASP.NET gaan programmeren en brakke sites bouwen die door zoekmachines en gehandicapten niet gebruikt kunnen worden.

Cookies zijn trouwens net zo goed user input als GET en POST.

[HuHu]

ajakkes schreef op donderdag 19 augustus 2010 @ 15:38:
Als post data verzonden kan worden zonder een submit knop moet het toch ook mogelijk zijn om de session_id() te verzenden zonder submit via post.

Indeed omslachtig. (not gonna happen).

Je kan prima de sessie_id aanpassen, of deze nu in een cookie, post of get wordt meegezonden. De keuze voor 1 van de 3 gaat je site echt niet veiliger of onveiliger maken, of wat je dan ook denkt.

CodeCaster schreef op donderdag 19 augustus 2010 @ 15:41:
[...]

Ja hoor, je kunt met javascript alle links zodanig bewerken dat ze je sessie-id en een link-id meeposten bij iedere klik. Wat boeit het als iemand zijn sessie_id aanpast? Dan krijgt 'ie een nieuwe sessie, en dan? Geen probleem toch? Je moet het alleen beveiligen tegen overname van sessie door een andere gebruiker, maar dat moet je sowieso.

Dat kun je beter server-side doen en niet met JavaScript.

[Voor 11% gewijzigd door HuHu op 19-08-2010 15:51]

[ajakkes]

@CodeCaster
Where did it go wrong?

1. Met sessie's werken
2. De site toegankelijk maken voor gebruikers zonder cookies
3. De site url's schoon houden

Al met al doelstellingen die de toegankelijkheid verhogen.
Ik begrijp ook wel dat eisen dat cookies geaccepteerd worden het hele verhaal een stuk makkelijker maakt.

Waarom gaat een zoekmachine of gehandicapte struikelen over mijn site als de SID naar de server wordt verzonden via post? Mocht dat zo zijn kan je nog niet van mij verwachten dat ik dat door zou hebben als ik niet eens weet hoe je de variabele in post krijgt.

Vandaar dat ik je opmerking totaal niet snap.

Edit:
Voor de duidelijkheid
Ik ben de topic gestart vanwege de tweede doelstelling
Mochten er nette manieren zijn om deze drie doelstellingen te bereiken zal ik ze meteen gebruiken. Echter wordt er bij 50% van de antwoorden hier gegeven vanuit gegaan dat de cookies geaccepteerd worden.
Als dat zo was had ik de vraag niet hoeven stellen.

[Voor 24% gewijzigd door ajakkes op 19-08-2010 15:59. Reden: Doelstelling nog eens duidelijk maken.]

[HuHu]

Hoe kun je dan zeggen dat je het verschil tussen POST en GET weet, als je niet weet hoe je een variabele in de POST krijgt?

[ajakkes]

Ik weet niet hoe je een variabele in de post krijgt zonder op submit te drukken. Zonder formulieren te gebruiken.
Als het al mogelijk is.

[CodeCaster]

HuHu schreef op donderdag 19 augustus 2010 @ 15:50:

Dat kun je beter server-side doen en niet met JavaScript.

Nee, dat kun je beter gewoon helemaal niet doen. Geen cookies betekent gewoon geen loginfunctionaliteit.

ajakkes schreef op donderdag 19 augustus 2010 @ 15:55:
@CodeCaster
Where did it go wrong?

1. Met sessie's werken
2. De site toegankelijk maken voor gebruikers zonder cookies
3. De site url's schoon houden

Al met al doelstellingen die de toegankelijkheid verhogen.
Ik begrijp ook wel dat eisen dat cookies geaccepteerd worden het hele verhaal een stuk makkelijker maakt.

ajakkes schreef op donderdag 19 augustus 2010 @ 16:02:
Ik weet niet hoe je een variabele in de post krijgt zonder op submit te drukken. Zonder formulieren te gebruiken.
Als het al mogelijk is.

Voor een eenvoudige website met hier en daar een formulier hoef je niet afhankelijk te zijn van cookies of sessievariabelen. Dus vertel eens welk probleem je op denkt te lossen met dit sessie-id- en post-verhaal.

En URL's "schoon" houden doe je niet met alles naar index.php?page=paginanaam te laten verwijzen. Kijk eens in de programming FAQ naar mod_rewrite en multiviews.

[Voor 18% gewijzigd door CodeCaster op 19-08-2010 16:07]

[ajakkes]

@CodeCaster

Er worden allerlei discussies gevoerd maar mijn begin vraag wordt over het hoofd gezien.

1. Is het mogelijk om de sessie vast te houden als de client geen cookies accepteerd en er een post formulier verzonden moet worden? Ja, maar de SID in de url is niet zo mooi.
2. Is het mogelijk om de SID niet in de URL op te slaan als er geen cookies geaccepteerd worden? Ja, dat is een optie als er een post formulier is.
3. Is het mogelijk om zonder cookies en post formulier en geen SID in de url de sessie vast te houden? Ja, maar dat doe je gewoon niet.

Of het legitiem is om een sessie te gebruiken is toch helemaal niet belangrijk?
Of ik een site wil bouwen met "no-cookie" support is toch aan mij en niet aan jou?
Als jij vind dat dit te lastig is om toe te passen en het daarom niet doet (en niet over na wil denken) hoor je mij daar niet over klagen.

Als ik vindt dat het niet te doen is om "no-cookie" te supporten zal ik deze optie laten vervallen. Maar daarom heb ik nog steeds al het recht om te vragen of iemand hier een oplossing voor weet.

[CodeCaster]

ajakkes schreef op donderdag 19 augustus 2010 @ 16:28:
@CodeCaster

Er worden allerlei discussies gevoerd maar mijn begin vraag wordt over het hoofd gezien.

1. Is het mogelijk om de sessie vast te houden als de client geen cookies accepteerd en er een post formulier verzonden moet worden? Ja, maar de SID in de url is niet zo mooi.

Ja, dat kan.

2. Is het mogelijk om de SID niet in de URL op te slaan als er geen cookies geaccepteerd worden? Ja, dat is een optie als er een post formulier is.

Ja, en dan moet je achter iedere link een stuk javascript hangen dat de link en het sessie-id post pagina waar de link heen verwijst. Veel plezier met testen.

3. Is het mogelijk om zonder cookies en post formulier en geen SID in de url de sessie vast te houden? Ja, maar dat doe je gewoon niet.

Hoe dan?

Of het legitiem is om een sessie te gebruiken is toch helemaal niet belangrijk?
Of ik een site wil bouwen met "no-cookie" support is toch aan mij en niet aan jou?
Als jij vind dat dit te lastig is om toe te passen en het daarom niet doet (en niet over na wil denken) hoor je mij daar niet over klagen.

Als ik vindt dat het niet te doen is om "no-cookie" te supporten zal ik deze optie laten vervallen. Maar daarom heb ik nog steeds al het recht om te vragen of iemand hier een oplossing voor weet.

Ik vraag me alleen hardop af welk probleem je hiermee nou op probeert te lossen, rustig maar hoor

[prutsger]

Om misschien enigszins te kunnen bijdragen: ik ben zelf webdeveloper en iemand die geen cookies accepteert. Ik ben van mening dat iemand die cookies bewust uitzet, ook wel weet dat sessies dan niet werken en je niet kunt inloggen op een site of een winkelwagentje kunt vullen. In de gevallen dat ik dat dus wel wil zet ik een site op de whitelist (zoals tweakers ). Dus ik zou echt geen moeite gaan doen om sessies te ondersteunen voor mensen die geen cookies accepteren, zonde van je tijd!

[ajakkes]

Tnx, voor de link als antwoord op mijn eerste vraag. Volgens mij staat daar hele nuttige info in.

Ik dacht dat mijn vragen eigenlijk al heel duidelijk waren. Blijkbaar helpt het opnieuw formuleren van de vragen om de goede antwoorden te krijgen.

Ik wil de site zo toegankelijk mogelijk houden/niet afhankelijk zijn van browser-instellingen. Ik begrijp dat je zo af en toe concessies moet doen. Maar zoals het er nu voor staat is dat voor dit geval helemaal niet nodig.

Bij mod_rewrite zal in mijn verhaal (geen cookie) alsnog de SID in de url blijven staan.

Maar het is veel makkelijker om de sessie vast te houden zonder cookies dan ik denk. Als ik het goed begrijp moet ik eerst nog eens naar mijn php instellingen kijken. Ik ga me er eens in verdiepen.

Bedankt voor deze nuttige post.

Edit:
@prutsger:
Tnx voor je point of view. Dat is hoe ik het zelf ook meestal aanpak. Maar omdat ik te lui ben om een whitelist te onderhouden komt het meestal neer op "geen cookies van derden" en de rest zo af en toe verwijderen. Vandaar toch goed om te horen hoe iemand met de instelling "geen cookies" over dit geval denkt.

Blijkbaar bij elke site die de moeite waard is om in te loggen ook whitelisten.

[Voor 20% gewijzigd door ajakkes op 19-08-2010 17:04. Reden: Reactie Prutsger]

[Manuel]

@prutsger: Dat ben ik dus met je eens. Indien de gebruiker graag wil inloggen en heeft zijn cookies uitstaan lijkt mij het vriendelijker gewoon een kleine notificatie neer te zetten in de trend van: 'Deze website maakt gebruik van cookies om u te laten inloggen' (wie weet kan iemand wel een betere verzinnen ).

@ajakkes: Ik ben ook van mening dat je moet doen wat je niet laten kan, het is zeker erg leerzaam maar of het enigszins nut heeft is een tweede vraag. Als ik jou was zou ik voor een simpele notificatie gaan (simpel aan de client-side te controleren). Dat kost je namelijk minder (werk)uren dat je aan je applicatie moet besteden.

Maar goed, zoals je zelf ook reeds aangeeft, deze keuze ligt bij jou en wij hebben deze maar te respecteren.