Hoe zet en lees ik een cookie?

[Johan Wevers]

Hallo,

Dit natuurlijk is wel erg basic, maar een duidelijke uitleg hierover
kon ik via Google niet vinden. Als ik een cookie wil zetten, is het
dan voldoende om op de index pagina een programma aan te roepen dat
als header

Content-type: text/html
Set-Cookie: Name=iets; expires=datum

meegeeft, en verder een lege html pagina? Of kan ik de index pagina
beter laten genareren door een programma? Ik kan hele lijsten vinden
welke waarden je er allemaal in kunt stoppen, maar dit niet.

Verder, hoe krijgen andere pagina's toegang tot dat cookie? Wordt dat
iedere keer dat je een pagina op die site oproept (zolang niet beperkt
door een Path waarde) automatisch meegestuurd en kan ik dat in een
ander programma dat op die site angeroepen wordt uitlezen in de
omgevingsvariabele HTTP_COOKIE?

--
ir. J.C.A. Wevers // Physics and science fiction site:
johanw@vulcan.xs4all.nl // http://www.xs4all.nl/~johanw/index.html
PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html

[Rene Pijlman]

Johan Wevers:
>Als ik een cookie wil zetten, is het dan voldoende om op de index pagina
>een programma aan te roepen dat als header
>
>Content-type: text/html
>Set-Cookie: Name=iets; expires=datum
>
>meegeeft, en verder een lege html pagina?

Ik kan me weinig voorstellen bij "op de index pagina een programma
aanroepen". En met een lege HTML-pagina is de bezoeker niet blij :-)

>Of kan ik de index pagina beter laten genareren door een programma?

Dat is de normale manier. Dat programma is vaak de PHP-engine, of iets
vergelijkbaars.

>Verder, hoe krijgen andere pagina's toegang tot dat cookie? Wordt dat
>iedere keer dat je een pagina op die site oproept (zolang niet beperkt
>door een Path waarde) automatisch meegestuurd

Inderdaad. De browser stuurt het mee in de vorm van een HTTP-header.

>en kan ik dat in een ander programma dat op die site angeroepen wordt
>uitlezen in de omgevingsvariabele HTTP_COOKIE?

Hoe je het precies kunt uitlezen kun je het beste opzoeken in de
handleiding van de programmeeromgeving die je gebruikt.

--
René Pijlman

Wat wil jij leren? http://www.leren.nl

[Johan Wevers]

Rene Pijlman wrote:

> Ik kan me weinig voorstellen bij "op de index pagina een programma
> aanroepen".

In de indexpagina iets als <img src="setcookie.exe"> opnemen, en die exe
dan een plaatje uit laten spugen en tevens een cookie header mee laten
sturen. Dit is de eerste keer dat ik zo'n werk doe, dus sommige
basisdingen moet ik nog leren.

>En met een lege HTML-pagina is de bezoeker niet blij :-)

Dat snap ik. :-)

> Dat is de normale manier. Dat programma is vaak de PHP-engine, of iets
> vergelijkbaars.

In dit geval wordt het dynamische deel in Delphi geschreven, het geheel
draait op Apache 2.0 onder windows 2000. Met Delphi heb ik ruime ervaring,
met de rest vrijwel niks (tot nu toe alleen statische html pagina's
gemaakt).

> Inderdaad. De browser stuurt het mee in de vorm van een HTTP-header.
>
> >en kan ik dat in een ander programma dat op die site angeroepen wordt
> >uitlezen in de omgevingsvariabele HTTP_COOKIE?
>
> Hoe je het precies kunt uitlezen kun je het beste opzoeken in de
> handleiding van de programmeeromgeving die je gebruikt.

Dat snap ik, en omgevingsvariabelen uitlezen en parsen is geen probleem,
dat doe ik nu al met de variabele QUERY_STRING. Maar als je een cookie
gezet hebt dat nog geldig is, dan zit er tussen de omgevingsvariabelen
automagisch die HTTP_COOKIE? Dan is het simpel.

Het volgende probleem wordt het aanpassen van de expire tijd (als de
gebruiker een uur niks doet verloopt de sessie, maar als hij weer iets
doet krijgt hij weer een uur). Daar zijn vast ook standaard methoden
voor.

--
ir. J.C.A. Wevers // Physics and science fiction site:
johanw@vulcan.xs4all.nl // http://www.xs4all.nl/~johanw/index.html
PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html

[Rene Pijlman]

Johan Wevers:
>In de indexpagina iets als <img src="setcookie.exe"> opnemen, en die exe
>dan een plaatje uit laten spugen en tevens een cookie header mee laten
>sturen. Dit is de eerste keer dat ik zo'n werk doe, dus sommige
>basisdingen moet ik nog leren.

Dit idee moet je ontleren :-)

>Dat snap ik, en omgevingsvariabelen uitlezen en parsen is geen probleem,
>dat doe ik nu al met de variabele QUERY_STRING. Maar als je een cookie
>gezet hebt dat nog geldig is, dan zit er tussen de omgevingsvariabelen
>automagisch die HTTP_COOKIE?

Ik kan het in de documentatie van Apache - en in de CGI spec waarnaar die
verwijst - niet terugvinden, maar Apache geeft cookies via CGI dacht ik
inderdaad door in de omgevingsvariabele HTTP_COOKIE.

Maar ik weet niet of je met Delphi/Apache/Windows gebruik maakt van CGI.

>Het volgende probleem wordt het aanpassen van de expire tijd (als de
>gebruiker een uur niks doet verloopt de sessie, maar als hij weer iets
>doet krijgt hij weer een uur). Daar zijn vast ook standaard methoden
>voor.

Brrr... je bent een compleet web application framework aan het schrijven.
Dat mag natuurlijk, maar er zijn er al zoveel!

Denk je ook aan het tegengaan van cookie spoofing?

--
René Pijlman

Wat wil jij leren? http://www.leren.nl

[Johan Wevers]

Rene Pijlman wrote:

> Dit idee moet je ontleren :-)

Het moet dus via de index pagina. Dan zal ik Apache wel moeten africhten
om een executable als default index file te accepteren, anders gaat de
klant niet accoord.

> Ik kan het in de documentatie van Apache - en in de CGI spec waarnaar die
> verwijst - niet terugvinden, maar Apache geeft cookies via CGI dacht ik
> inderdaad door in de omgevingsvariabele HTTP_COOKIE.
>
> Maar ik weet niet of je met Delphi/Apache/Windows gebruik maakt van CGI.

Bij mijn weten wel: in Delphi heb ik een console app gemaakt, die de html
gewoon via writeln() doorgeeft. Dat stuk werkt al, en het uitlezen en erin
verwerken van de voorraad in een database ook.

> Brrr... je bent een compleet web application framework aan het schrijven.
> Dat mag natuurlijk, maar er zijn er al zoveel!

Als ik de handleidingen van de al bestaande Delphi classes op dat gebied
eens bekijk kost het me meer tijd om dat te leren gebruiken dan om alles
low-level zelf te schrijven.

Het lezen van QUERY_STRING als omgevingsvariabele is ook geen probleem,
en het opsplitsen daarvan in losse stukken en die koppelen aan
programmavariabelen werkt ook. Het programma ziet wat ik doorgeef. Toen
ik eenmaal doorhad hoe dat werkte was dat vlug genoeg geprogrammeerd.

> Denk je ook aan het tegengaan van cookie spoofing?

Dat is? Iemand die een vals cookie meegeeft? Daar ga ik me niet druk om
maken. Het is een site waar iemand postzegels kan bestellen. De inhoud
van een winkelwagentje wordt natuurlijk per user bijgehouden. Die expire
is nodig om te voorkomen dat artikelen gereserveerd worden in de voorraad
en nooit meer vrijgegeven worden als de client niks meer van zich laat
horen.Ik denk dat ik het risico dat iemand met valse gegevens iets anders
zou willen kopen dan hij toch al aangevinkt had te verwaarlozen is.

--
ir. J.C.A. Wevers // Physics and science fiction site:
johanw@vulcan.xs4all.nl // http://www.xs4all.nl/~johanw/index.html
PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html

[Rene Pijlman]

Johan Wevers:
>Als ik de handleidingen van de al bestaande Delphi classes op dat gebied
>eens bekijk kost het me meer tijd om dat te leren gebruiken dan om alles
>low-level zelf te schrijven.

Merkwaardig. Deze conclusie ben ik zelfs in de PHP-wereld nog niet
tegengekomen.

>Het lezen van QUERY_STRING als omgevingsvariabele is ook geen probleem,
>en het opsplitsen daarvan in losse stukken en die koppelen aan
>programmavariabelen werkt ook. Het programma ziet wat ik doorgeef. Toen
>ik eenmaal doorhad hoe dat werkte was dat vlug genoeg geprogrammeerd.

>> Denk je ook aan het tegengaan van cookie spoofing?
>
>Dat is? Iemand die een vals cookie meegeeft? Daar ga ik me niet druk om
>maken. Het is een site waar iemand postzegels kan bestellen. De inhoud
>van een winkelwagentje wordt natuurlijk per user bijgehouden. [...]
>Ik denk dat ik het risico dat iemand met valse gegevens iets anders
>zou willen kopen dan hij toch al aangevinkt had te verwaarlozen is.

Het risico is dat iemand met een vals cookie de sessie van iemand anders
kan overnemen, en misschien creditcardgegevens kan aftappen. Goede cookies
worden daarom onvoorspelbaar en veelbitterig gegenereerd.

Het is nogal theoretisch, maar dit soort dingen krijg je kado als je een
volwassen webapplicatieframeworkgebeuren gebruikt.

--
René Pijlman

Wat wil jij leren? http://www.leren.nl

[Johan Wevers]

Rene Pijlman wrote:

>>Als ik de handleidingen van de al bestaande Delphi classes op dat gebied
>>eens bekijk kost het me meer tijd om dat te leren gebruiken dan om alles
>>low-level zelf te schrijven.

> Merkwaardig. Deze conclusie ben ik zelfs in de PHP-wereld nog niet
> tegengekomen.

Dat kan ook iets zeggen over php als taal om low-level zaken in te
schrijven, of de kunde van degenen die het gebruiken. Als ik eenmaal
doorheb hoe het werkt is het schrijven makkelijk. Het meeste werk gaat
momenteel zitten in het doorkrijgen van dit soort basisdingen.

> Het risico is dat iemand met een vals cookie de sessie van iemand anders
> kan overnemen, en misschien creditcardgegevens kan aftappen.

Ah zo. Betalingsgegevens gaan niet over de lijn: bij een bestelling
wordt er een email gestuurd naar de beheerder, die vervolgens wacht
tot het geld overgemaakt is en dan de spullen opstuurt.

> Goede cookies worden daarom onvoorspelbaar en veelbitterig gegenereerd.

Een pseudo-randomgenerator is niet zo lastig te schrijven (daar heb ik
al genoeg codevoorbeelden van). Ik wilde die cookies toch al componeren
als value=(datum)(tijd)(random value) om te garanderen dat ze uniek zijn.

> Het is nogal theoretisch, maar dit soort dingen krijg je kado als je een
> volwassen webapplicatieframeworkgebeuren gebruikt.

Vast wel. Maar dit is niet iets wat me veel tijd zal kosten.

--
ir. J.C.A. Wevers // Physics and science fiction site:
johanw@vulcan.xs4all.nl // http://www.xs4all.nl/~johanw/index.html
PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html

[John Bokma]

Johan Wevers wrote:

> Een pseudo-randomgenerator is niet zo lastig te schrijven (daar heb ik
> al genoeg codevoorbeelden van). Ik wilde die cookies toch al componeren
> als value=(datum)(tijd)(random value) om te garanderen dat ze uniek zijn.

Eh, dat garandeer je zo natuurlijk niet :-D.

>> Het is nogal theoretisch, maar dit soort dingen krijg je kado als je een
>> volwassen webapplicatieframeworkgebeuren gebruikt.
>
> Vast wel. Maar dit is niet iets wat me veel tijd zal kosten.

Ik had het idee dat je al een tijdje bezig was met Delphi + CGI e.d.

Mijn ervaring is dat het heel vaak loont om even door te bijten en een
library te beheersen ipv het wiel uit te vinden. CGI lijkt simpel, maar er
kunnen veel dingen mis gaan. Waarom dat opnieuw ontdekken?

--
John Voorbeeldscripts in Perl: http://johnbokma.com/perl/
Website design: http://johnbokma.com/websitedesign/
Ervaren Perl / Java programmeur beschikbaar: http://castleamber.com/
Tevreden opdrachtgevers: http://castleamber.com/testimonials.html

[Johan Wevers]

John Bokma wrote:

>> Een pseudo-randomgenerator is niet zo lastig te schrijven (daar heb ik
>> al genoeg codevoorbeelden van). Ik wilde die cookies toch al componeren
>> als value=(datum)(tijd)(random value) om te garanderen dat ze uniek zijn.

> Eh, dat garandeer je zo natuurlijk niet :-D.

Theoretisch niet nee. Praktisch gezien wel. Als ik cookies opbouw als
(datum)(tijd)(random getal) moet het wel heel druk worden
wil ik problemen krijgen. Tenzij de randomgenerator niet deugt natuurlijk.

Als ik tijd tot op honderdsten seconden nauwkeurig neem zit ik
waarschijnlijk ook wel safe: de server is te traag om binnen die
tijd meerdere connecties op te bouwen. :-) (het moet bij de klant
thuis op een ADSL lijn gaan werken).

> Ik had het idee dat je al een tijdje bezig was met Delphi + CGI e.d.

Ja, maar ik heb ook nog veel andere dingen te doen. Ik werk er geen uren
aan een stuk aan.

> Mijn ervaring is dat het heel vaak loont om even door te bijten en een
> library te beheersen ipv het wiel uit te vinden. CGI lijkt simpel, maar er
> kunnen veel dingen mis gaan. Waarom dat opnieuw ontdekken?

Weten hoe iets werkt vind ik altijd belangrijk. Bovendien zijn de meeste
libraries in Perl of PHP geschreven, in Delphi vind ik gewoonlijk alleen
codevoorbeelden of commerciele libs (en het mag niks kosten).

--
ir. J.C.A. Wevers // Physics and science fiction site:
johanw@vulcan.xs4all.nl // http://www.xs4all.nl/~johanw/index.html
PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html

[Johan Wevers]

Rene Pijlman wrote:

>>In de indexpagina iets als <img src="setcookie.exe"> opnemen, en die exe
>>dan een plaatje uit laten spugen en tevens een cookie header mee laten
>>sturen. Dit is de eerste keer dat ik zo'n werk doe, dus sommige
>>basisdingen moet ik nog leren.

> Dit idee moet je ontleren :-)

OK, ik heb nu een index.html met darain in de header een regel:
<meta HTTP-EQUIV="REFRESH" content="0; url=index.exe">
en dat werkt uitstekend (nadat ik ExecCGI voor de document root
aangezet had in Apache).

> Ik kan het in de documentatie van Apache - en in de CGI spec waarnaar die
> verwijst - niet terugvinden, maar Apache geeft cookies via CGI dacht ik
> inderdaad door in de omgevingsvariabele HTTP_COOKIE.

Klopt. Wel vreemd dat ik in die variabele nu waarden krijg als
NAME=123456789 i.p.v. alleen 123456789, maar dat kan het programma
er wel weer afstrippen.

--
ir. J.C.A. Wevers // Physics and science fiction site:
johanw@vulcan.xs4all.nl // http://www.xs4all.nl/~johanw/index.html
PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html

[Rene Pijlman]

Johan Wevers:
>OK, ik heb nu een index.html met darain in de header een regel:
><meta HTTP-EQUIV="REFRESH" content="0; url=index.exe">
>en dat werkt uitstekend (nadat ik ExecCGI voor de document root
>aangezet had in Apache).

Lieve help! Een client-afhankelijkheid, een extra HTTP-request én een
CGI-aanroep voor elke bevraging van de root. Om over zoekmachines maar te
zwijgen.

De opdrachtgever en zijn webbezoekers betalen een hoge prijs voor de
kennelijk nogal dringende wens om de vele meer dan uitstekende
kant-en-klaar oplossingen te vermijden :-)

--
René Pijlman

Wat wil jij leren? http://www.leren.nl

[Johan Wevers]

Rene Pijlman wrote:

> Lieve help! Een client-afhankelijkheid,

Met standaardtekst in de trand van "klik hier als u niet automatisch
doorgelinkt wordt".

> een extra HTTP-request én een
> CGI-aanroep voor elke bevraging van de root. Om over zoekmachines maar te
> zwijgen.
>
> De opdrachtgever en zijn webbezoekers betalen een hoge prijs voor de
> kennelijk nogal dringende wens om de vele meer dan uitstekende
> kant-en-klaar oplossingen te vermijden :-)

Hoe zou jij dat dan oplossen? Ik zou ook een server redirect kunnen doen
natuurlijk.

--
ir. J.C.A. Wevers // Physics and science fiction site:
johanw@vulcan.xs4all.nl // http://www.xs4all.nl/~johanw/index.html
PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html

[Rene Pijlman]

Johan Wevers:
>Hoe zou jij dat dan oplossen? Ik zou ook een server redirect kunnen doen
>natuurlijk.

Ik snap niet waarom je een redirect wilt doen.

De normale gang van zaken is:
1. Client vraagt een contentpagina aan server.
2. Server checkt aanwezigheid en geldigheid van cookie. Die is er niet.
Server stuurt loginpagina.
3. Client submit user/password naar server.
4. Server checkt password, creëert sessie en stuurt de gewenste
contentpagina terug met een cookie.
5. Bij elke volgende pagina stuurt de client het cookie mee (tot sluiten
browser of expiren persistent cookie).

En dit gebeuren zit standaard in web application frameworks als PHP, J2EE,
IIS/.net, Zope, you name it. Die dingen draaien als 'daemon', of zelfs in
het webserver-proces en worden dus niet per request via CGI ge-fork'ed.
Het is bovendien niet ahankelijk van client-side grappen en grollen als
images en HTTP-EQUIV-refreshes. Wel van cookie-ondersteuning natuurlijk,
maar dat is onvermijdelijk als je met cookies wilt werken :-)

--
René Pijlman

Wat wil jij leren? http://www.leren.nl

[Johan Wevers]

Rene Pijlman wrote:

> De normale gang van zaken is:
> 1. Client vraagt een contentpagina aan server.
> 2. Server checkt aanwezigheid en geldigheid van cookie. Die is er niet.
> Server stuurt loginpagina.

Dat is niet nodig, er hoeft helemaal niet ingelogd te worden.

> 3. Client submit user/password naar server.

Die zijn er dus niet.

> En dit gebeuren zit standaard in web application frameworks als PHP, J2EE,
> IIS/.net, Zope, you name it.

Maar zo moet het dus niet gaan werken.

--
ir. J.C.A. Wevers // Physics and science fiction site:
johanw@vulcan.xs4all.nl // http://www.xs4all.nl/~johanw/index.html
PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html