[perl/cookie] bereken relatieve expire datum

[RolandWitvoet]

Ik wil een cookie zetten dat blijft bestaan gedurende een door de gebruiker opgegeven tijd. Dit kan varieren van +1s tot +10y of zo, de gebruiker kan aangeven welke (tijds)eenheid en hoeveel eenheden de levensduur van het cookie moet zijn. Het doel is natuurlijk om een persistent session te maken.

Cookie setten is het probleem niet, gewoon zeggen dat het cookie over "+7d" verloopt, de browser rekent wel uit wanneer het cookie weg mag en geeft het cookie niet meer door na die tijd. Maar omdat je nooit moet vertrouwen op wat de browser je verteld wil ik in perl, serverside uitrekenen (en opslaan) wanneer het cookie moet verlopen.
Nou zijn de standaard datum/tijd-functies van perl (Time.pm) niet zo handig. je kunt niet even x dagen optellen bij de day-value en dan de seconden opvragen met timelocal.
Uitrekenen wanneer het 31 dagen later is door 31 op te tellen bij de dag-waarde:
timelocal(59,59,23,18+31,12,2003) werkt niet omdat je dan een "out of range 1..31" krijgt voor de 18+31.
Het zou erg makkelijk zijn als het wel zou werken

Ander uiterste is om zelf rekening te houden met variabelen die over hun maximum gaan. Dat is voor uren minuten en seconden nog wel te doen, maar bij dagen moet je al rekening gaan houden met hoeveel dagen er in een maand zitten en dus ook met schrikkeljaren. Ik moet bijna een halve kalender gaan maken Het levert een erg ontsierend rijtje while-loopjes op

Ik kan me niet voorstellen dat dat niet makkelijker kan en/of niemand daar al eens iets voor gemaakt heeft. Elke browser rekent die datum uit, serverside, in perl, moet dat toch ook eenvoudig kunnen? Ik ben vast niet de eerste die wil uitrekenen wanneer de "+31d" van een cookie-lifetime is.

[ Voor 41% gewijzigd door RolandWitvoet op 18-12-2003 02:15 ]

[Verwijderd]

meschien een smerige work around.
maar ik ben ook nooit zo'n ster geweest met werken met datums enzo
dus ik pak dan altijd de `date +%s` van het systeem.
die geeft het aantal seconden terug sinds 00:00:00, Jan 1, 1970
dan breng je de selecte van de gebruiker terug tot seconden.
en tel je die bij de terug gekregen waarde op.

[Soultaker]

De 'timestamp' (het aantal seconden sinds de 'UNIX epoch' van 1 januari 1970) kan je ook in Perl opvragen met de time() functie. Aangezien dat een aantal seconden is, kun je daar dagen bij optellen door per dag 24*60*60 == 86400 op te tellen. Vervolgens kun je die timestamp met allerhande functies (zoals localtime/gmtime of strftime) weer omzetten in een ander formaat.

[RolandWitvoet]

Bij beide 'oplossingen' is er het probleem dat als de gebruiker +1M (1 maand) opgeeft dat dit geen vast aantal seconden is. Op 1 januari is +1M 31*24*60*60 seconden, op 1 februari is het maar 28*24*60*60 seconden (behalve in schrikkeljaren natuurlijk).
Momenteel doe ik het inderdaad door er gewoon x seconden bij op te tellen. Zekerheidshalve neem ik maar 28 dagen voor een maand (beter een cookie dat te snel vervalt dan een die te lang blijft), maar een jaar is daardoor nog maar 336 dagen lang.

Daar komt nog eens bij dat ik een flinke reeks if-statements heb staan om die +1s, +1m, +1h, +1d, etc. te vertalen naar seconden. Terwijl ik gewoon voel dat ik niet de eerste zal zijn die die cookie houdbaarheidsdatum om wil zitten naar een exacte datum.

[phreggle]

Volgens mij doet 'date -d' gewoon precies wat jij wil. Hier wat voorbeeldjes:

code:

phreggle@anouk:~$ date -d '+1 second'
Thu Dec 18 04:49:27 CET 2003
phreggle@anouk:~$ date -d '+7 days'
Thu Dec 25 04:49:34 CET 2003
phreggle@anouk:~$ date -d '+10 year'
Wed Dec 18 04:49:41 CET 2013
phreggle@anouk:~$

Dit werkt iig onder linux zo. Onder freebsd werkt het iets anders, maar daar is ook ooit een topic over geweest. Ik zal eens ff zoeken.

Deze dus: [rml][ shell]Date probleempje[/rml]/

[ Voor 13% gewijzigd door phreggle op 18-12-2003 04:53 ]

[RolandWitvoet]

Precies wat ik zocht! heel erg bedankt

Op een redhat systeem staat in de man date:

-d, --date=STRING
display time described by STRING, not now

Niet echt dat ik zeg "ja, dat is het" maar het is het inderdaad wel.

Hmm.. "[toad]"? een mede-Stacker (Ex-stacker inmiddels zie ik)

[ Voor 17% gewijzigd door RolandWitvoet op 18-12-2003 05:17 ]

[phreggle]

Soms is uit de info pages veel meer te halen dan uit de man pages, beetje wazig maarja.

Hmmja ik ben wel ooit lid geweest van stack maar dat was toen voor de shell accounts. Verder ben ik er nooit echt geweest ofzo.

[ Voor 45% gewijzigd door phreggle op 18-12-2003 05:24 ]

[RolandWitvoet]

Net als 95% van de leden ...

[phreggle]

Tja inderdaad, maar voor de gezelligheid ga ik wel ergens anders heen...
Ik weet niet in hoeverre jij betrokken bent bij stack en of ik je nu op de tenen trap, maar als je daar soms naar binnen kijkt dan zitten me daar soms toch een partij enge mensen. (ja, dit is ook een vooroordeel )

[RolandWitvoet]

Ik heb er een accountje (redman), meer niet. De hoegaarden-borrels en D&D-competieties trekken me absoluut niet. Enge mensen zijn het niet hoor, ze doen je niets en kunnen heel behulpzaam zijn. Ze hebben de zaken wel goed voor elkaar, ik ken weinig providers die nog shell accounts aanbieden en als ze het doen wordt ik meestal binnen een jaar verwijderd omdat ze er achter komen dat ik dingen kan doen die zij niet willen. Dan is het makkelijker om die ene persoon die de shell account gebruikt weg te schoppen dan de server goed te configgen

maar mail of icq me maar als je wilt chatten, anders wordt het hier een HK-topic (en ik kan gelukkig niet in de HK)

[ Voor 11% gewijzigd door RolandWitvoet op 22-12-2003 08:50 ]

[curry684]

RolandWitvoet schreef op 22 december 2003 @ 08:48:
maar mail of icq me maar als je wilt chatten, anders wordt het hier een HK-topic (en ik kan gelukkig niet in de HK)

offtopic:
met userid 21902 en jouw voorhistorie zie ik weinig problemen om HK-XS te krijgen hoor maar dit topic wordt wel iets te ver offtopic nu voor in P&W