[PHP] Session lifetime

[verytallman]

Na wat gelezen te hebben over sessies en het verlengen van de duur, kom ik toch op een probleem uit.
Bij een sessie wordt het cookie op de server opgeslagen, of iig niet op de pc van de gebruiker.
Als je nu een sessie verlengt zodat hij langer meegaat dan bij het sluiten van de browser, dan kan die persoon die ingelogd is daarna weer terugkomen en ingelogt zijn.
Maar nu is mijn vraag, hoe kan de server zien dat de 'openstaande' sessie bij die pc/gebruiker hoort?

Voorbeeld:
1. Login - sessie gegevens worden opgeslagen (id bijv)
2. User sluit browser en gaat weg
3. User komt terug en opent browser en is nog steeds ingelogt(vanuit gaande lifetime lang genoeg)

Het gaat om de laatste stap, hoe vind die herkenning plaats ?
Ik snap dat je het met een cookie zou kunnen doen, maar dat vind ik niet logisch want dan kun je niet zo goed je login met cookies(op de user pc) doen.

[Michali]

Als je wilt dat je nog ingelogd bent na het sluiten van de browser, dan moet je met koekjes werken anders lukt het niet. Je browser vensert heeft een bepaald ID waarmee de sessie steeds geopend wordt. Volgens mij wordt op basis de browser ID en je IP een key gemaakt oid (maar dat weet ik niet zeker). Puur met php sessies is dit niet mogelijk volgens mij.

[defl8te]

wanneer je een sessie start, wordt er een cookie aangeboden aan de client. In dit cookie staat de session id die gekoppeld is aan de sessie op server. Deze cookie kun je weigeren, op dat moment probeert php achter iedere link de sessie id te plakken (?sid=123456789), op deze manier wordt de server sessie gekoppeld aan de user sessie. Lokaal heb je dus alleen het sessie id in een cookie staan.

Dit is trouwens erg gemakkelijk te faken, stel ik kopieer jouw cookie met het sessie id erin, dan ben ik automagisch ingelogd onder jouw account... daarom moet je altijd ook een check op ip oid doen...

[ Voor 5% gewijzigd door defl8te op 19-02-2005 15:29 ]

[verytallman]

Dus een user die cookies accepteerd krijgt bij een sessie login systeem alsnog een cookie met zijn id erin op zn pc ?
Als je dan voor de veiligheid ook zijn ip in een cookie moet opslaan vraag ik me af waarom je nog sessies zou gebruiken en niet gewoon cookies(op de user pc)

[Gert]

Niet iedereen accepteert cookies. De meeste omgevingen ondersteunen ook cookieless sessions, dan wordt de sessie via de url bijgehouden, dit kan je ook forceren waardoor er nooit een cookie wordt gebruikt.

[JHS]

verytallman schreef op zaterdag 19 februari 2005 @ 15:40:
Als je dan voor de veiligheid ook zijn ip in een cookie moet opslaan vraag ik me af waarom je nog sessies zou gebruiken en niet gewoon cookies(op de user pc)

Je slaat het ip dan natuurlijk serverside op, en kijkt of dan het sessionid geleverd door de client en het ip van de client overeenkomen met de sessionid en ip die jij hebt opgeslagen in bijvoorbeeld een database, uit welke je ook de userid die bij die sessie haalt. Althans dat is één constructie, er zijn er vast nog wel meer mogelijk, maar dit lijkt me een generieke en veilige.

edit:

Overigens moet je wel rekening houden met gebruikers die langere sessies willen hebben en die niet een vast ip hebben. En idd gebruikers die geen cookies accepteren, maar dan kunnen ze ook niet ingelogd blijven .

[ Voor 15% gewijzigd door JHS op 19-02-2005 15:50 ]

[Soultaker]

De belangrijkste reden om sessies te gebruiken is dat je informatie op kunt slaan op de server in plaats van de (onbetrouwbare) client. Als je bijvoorbeeld de inhoud van een boodschappenwagentje op de client bijhoudt, dan kan de client prijzen van items in het wagentje wijzigen. Dat is heel irritant, want dan moet je op de server steeds de gegevens die je terugkrijgt volledig controleren, om te voorkomen dat er misbruik gemaakt wordt van je systeem. Hetzelfde geldt bijvoorbeeld voor rechten die een client op een forum heeft.

Als je dit soort informatie op de server opslaat, dan hoef je het in principe nooit te controleren. Je kunt makkelijk de inhoud van een winkelwagentje opslaan met prijzen en al, want je weet zeker dat die prijzen kloppen op het moment dat je ze er in stopt en aangezien niemand ze kan wijzigen, zullen ze geldig zijn als je ze er de volgende keer uithaalt.

Bijkomend voordeel is dat de client geen inzage heeft in de informatie die op de server is opgeslagen. Behalve dat je zo gegevens over een client achter kan houden, kun je zo ook de privacy beschermen, door bijvoorbeeld creditcardnummers niet in een cookie op te slaan, zodat ze ook niet plain-text over internet gaan of in te zien zijn door een willekeurige gebruiker die toevallig achter de computer kruipt.

[ Voor 14% gewijzigd door Soultaker op 19-02-2005 16:53 ]

[pierre-oord]

2 problemen nog over sessies:
1) IP check. Dat kan eigenlijk niet, als je via een proxy zit kun je vanaf meerdere IP's komen.
2) Dingen opslaan zou ik gewoon meteen in de database doen. Anders stuur je ze gewoon via GET/POST mee, en controleer je helemaal aan het einde of de bijeen verzamelde informatie klopt.

Ik heb met sessies wel last van problemen:
Ik heb de sessietijd op een maand of langer gezet. Alleen na een herstart van m'n PC ben ik toch eigenlijk altijd uitgelogd op de website (ik gebruikte sessies voor een login systeem), ondanks de lange houdbaarheid van het cookie. Nu heb ik het opgelost met cookies (een username + md5 password), wat erg goed werkt ik blijf nu echt steeds ingelogd.

Veilig zou een SSL sessie natuurlijk ook zijn, als je dan de cookies verstuurd, zijn ze ook niet te onderscheppen. En tsja, als een user bang is dat ze lokaal worden gestolen, dan moet je gewoon uitloggen van de pagina, of aangeven dat je koekje maar een uur geldig is

En mensen die geen cookies accepteren hebben voor mij gewoon pech, dan ga je maar weg

[Verwijderd]

verytallman schreef op zaterdag 19 februari 2005 @ 15:20:
Bij een sessie wordt het cookie op de server opgeslagen, of iig niet op de pc van de gebruiker.
Als je nu een sessie verlengt zodat hij langer meegaat dan bij het sluiten van de browser, dan kan die persoon die ingelogd is daarna weer terugkomen en ingelogt zijn.
Maar nu is mijn vraag, hoe kan de server zien dat de 'openstaande' sessie bij die pc/gebruiker hoort?

Voorbeeld:
1. Login - sessie gegevens worden opgeslagen (id bijv)
2. User sluit browser en gaat weg
3. User komt terug en opent browser en is nog steeds ingelogt(vanuit gaande lifetime lang genoeg)

Het gaat om de laatste stap, hoe vind die herkenning plaats ?

Bij het sluiten en opnieuw openen van de browser veranderd ook de sessie. Er is dan ook geen sprake van het verlengen van de sessie. Meest voorkomende techniek is denk ik het opnieuw aanmaken van een sessie en de gebruiker automatisch laten inloggen d.m.v. de cookie gegevens.

pseudo

code:

if (!($_SESSION['isloggedin']==false))
{ if (authenticate_cookie($_COOKIE['cookie_var1'],$_COOKIE['cookie_var2']))
  { $_SESSION['isloggedin']=true;
  }
  else
  { show_login = true;
  }
}
else
{ show_login = true;
}

edit: dus eigenlijk de methode die "pierre-oord" hierboven beschrijft.

[ Voor 6% gewijzigd door Verwijderd op 20-02-2005 00:31 ]

[crisp]

pierre-oord schreef op zaterdag 19 februari 2005 @ 19:03:
[...]Nu heb ik het opgelost met cookies (een username + md5 password), wat erg goed werkt ik blijf nu echt steeds ingelogd.

Persoonlijk zou ik nooit persoonlijke gegevens opslaan in een cookie; geen username of id en al helemaal geen wachtwoord of een hash daarvan. Maak dan zelf een sessie-id aan waaraan je die gegevens in je database koppelt, en communiceer alleen dat sessie-id.
Voordeel is dan ook dat je aan dat specifieke sessie-id kenmerken kan koppelen die alleen voor die sessie geleden. Je kan bijvoorbeeld je gebruiker bij het aanloggen de keuze geven of ze de sessie willen koppelen aan het ip-adres, of een bepaalde expire-time laten opgeven voor die specifieke sessie (serverside gooi je dan met bepaalde regelmaat expired sessies uit je sessietabel).
Eenmaal ingelogt kan je de gebruiker dan ook de mogelijkheid bieden andere openstaande sessies op hun userid te beeindigen. Je kan hits per sessie bijhouden, je kan het gebruiken als een challenge-mechanisme etcetera.

[ Voor 4% gewijzigd door crisp op 20-02-2005 00:51 ]

[pierre-oord]

crisp schreef op zondag 20 februari 2005 @ 00:49:
[...]

Persoonlijk zou ik nooit persoonlijke gegevens opslaan in een cookie; geen username of id en al helemaal geen wachtwoord of een hash daarvan. Maak dan zelf een sessie-id aan waaraan je die gegevens in je database koppelt, en communiceer alleen dat sessie-id.
Voordeel is dan ook dat je aan dat specifieke sessie-id kenmerken kan koppelen die alleen voor die sessie geleden. Je kan bijvoorbeeld je gebruiker bij het aanloggen de keuze geven of ze de sessie willen koppelen aan het ip-adres, of een bepaalde expire-time laten opgeven voor die specifieke sessie (serverside gooi je dan met bepaalde regelmaat expired sessies uit je sessietabel).
Eenmaal ingelogt kan je de gebruiker dan ook de mogelijkheid bieden andere openstaande sessies op hun userid te beeindigen. Je kan hits per sessie bijhouden, je kan het gebruiken als een challenge-mechanisme etcetera.

Eigenlijk dus zoals GoT werkt geloof ik?

Dit is inderdaad wel een mooi systeem. Maar zoals ik al zei: Bij mij lijken de sessies toch te vervallen, ondanks dat ik aangeef dat ze een maand geldig moeten blijven. Inderdaad is een mooi optie om aan een gebruiker de mogelijkheid te geven hun sessie aan hun IP te koppelen.

Maar voor zover ik weet worden op m'n server door PHP standaard de sessies in de /tmp map opgeslagen (die standaard bij het herstarten wordt gecleaned trouwens misschien toch maar andere directory kiezen, al herstart ik de server toch nooit )

Kun je sessies dan ook in een database zetten oid, jouw horende over een sessie tabel? En waarom vervallen bij mij de sessies; gooit PHP die soms zelf weg, en heb ik een optie in de config over het hoofd gezien soms?

edit:
@inaasappelsap: Als je de sessietijd langer zet, blijft volgens mij gewoon de sessie hetzelfde? In ieder geval pakt die hem dan weer op. Waarom na een herstart van m'n PC of een dag later ofzo, de sessie weer wordt vergeten, is mij alleen een raadsel.

Nu ik toch verder praat: Uiteindelijk wordt de sessie op je PC opgeslagen in een koekje.
Je zou dus eigenlijk zelf je eigen sessie moeten maken: Een koekje met een uniek ID (userid + timestamp bijvoorbeeld) en dat als je eigen "sessie ID" gebruiken, vervolgens die opslaan in een database waarin staat welke userid en password het is. Zo zou je dan meteen een nieuwe sessie met php kunnen aanmaken, en kunnen checken op een IP in de database. Dit klinkt alleen erg lastig en dom, 2 koekjes dus uiteindelijk. Het server-side cookie is erg handig, als het tenminste blijft werken, waarom het dat hier niet doet, geen idee.

edit:
Toen ik een week geleden nog met sessies alles had, had ik dit bovenaan staan in de php login:

session_set_cookie_params(30*24*60*60); // koekjes op een maand zetten
session_start();


Ook is het iets veiliger met cookie-sessions te werken dan met een sessie in je URL. PHP kan dat laatste automatisch voor je doen. Nadeel is dat het zeer gemakkelijk is om even een URL van iemand over te schrijven/mailen in een seconde, terwijl het kopieren van een cookie uit uitlezen ervan wat lastiger is.

[ Voor 31% gewijzigd door pierre-oord op 20-02-2005 15:30 ]

[PrisonerOfPain]

Soultaker schreef op zaterdag 19 februari 2005 @ 16:52:
De belangrijkste reden om sessies te gebruiken is dat je informatie op kunt slaan op de server in plaats van de (onbetrouwbare) client. Als je bijvoorbeeld de inhoud van een boodschappenwagentje op de client bijhoudt, dan kan de client prijzen van items in het wagentje wijzigen. Dat is heel irritant, want dan moet je op de server steeds de gegevens die je terugkrijgt volledig controleren, om te voorkomen dat er misbruik gemaakt wordt van je systeem.

offtopic:
Dan sla je toch echt de verkeerde gegevens op in je cookie . Alleen de id's van de producten opslaan is toch voldoende? Dan heeft de client er ook niks aan om ze aan te gaan passen. Dan kun je daarna de prijzen alsnog uit de database trekken. Of zie ik iets over het hoofd?

[Soultaker]

Nee, dat klopt helemaal, maar het punt is dus dat je dan meer werk moet doen om de zaak consistent te houden (de prijzen en producten elke keer uit de database halen). Dat kan altijd wel, maar je moet er harder over nadenken en meer moeite doen om het veilig te houden. De oplossing om dit soort gegevens op de server op te slaan is 'by default' veiliger.

Bovendien kun je de boel niet customizen voor de gebruiker. Als een prijs bijvoorbeeld wijzigt terwijl een klant aan het winkelen is, wil je misschien niet dat de prijs van het product in het winkelwagentje verandert (bijvoorbeeld). In zo'n geval moet je dus de prijs ergens bij de client specifiek opslaan, maar niet in zijn cookie. Dat kan dan wel in een session. Het alternatief is dat je per-session-data in een database gaat opslaan, maar dat is niet zo zinnig als het echt tijdelijke (session) informatie betreft, want als je met PHP werkt, waarom zou je dan functionaliteit die al aanwezig is opnieuw gaan implementeren?

Verder zijn er een aantal technische beperkingen, zoals dat een client geen grote cookies hoeft te accepteren en als je dus een wat per-session-data wil opslaan zijn cookies gewoon niet toereikend. Die data op de server opslaan is dan veel flexibeler.

[ Voor 9% gewijzigd door Soultaker op 20-02-2005 16:57 ]

[Janoz]

Wat is trouwens het probleem met session_set_save_handler? Best of both worlds. Hierdoor kun je de standaard php sessions blijven gebruiker en toch zelf bepalen hoe de gegevens opgeslagen en ook opgeruimd worden.