[PHP/SQL]Sessies in de database

[Tjolk]

Voor mijn site moet je inloggen om er gebruik van te maken. Zoals bij zoveel sites is er ook de mogelijkheid om de login te onthouden.

Om dit mogelijk te maken, heb ik zoiets in de PHP staan:

1. Creëer een eigen (non-PHP) sessie id met een random string
2. Stop die in een cookie
3. Voeg die toe aan een veld in de database (bij de rij van die gebruiker), scheid daarin de id's d.m.v. een puntkomma.
4. Vergelijk bij het bezoeken van de pagina de sessie id in de cookie met de waarden in de database.
5. Als iemand uitlogt (via de knop) wordt de cookie verwijderd en de bijbehorende sessie id uit de database gehaald.

Dat werkt goed, maar er is één "probleem". Als iemand zijn cookies handmatig verwijderd, wordt dit natuurlijk niet doorgegeven aan de database. Daar blijft dan een nutteloze sessie id achter die nooit meer gebruikt wordt. Dit is op zich natuurlijk geen ramp (er zijn onuitspreekbaar veel mogelijkheden voor het sessie_id, dus niemand zal het daardoor kunnen hijacken), maar op den duur kan de database hierdoor redelijk vervuild raken.

Een mogelijke oplossing die in me opkomt is een aparte tabel aanmaken voor de sessies, en op basis van de sessie kijken welke gebruker daarbij hoort. Nu doe ik dat nog andersom: de sessies worden opgeslagen in de tabel van de gebruikers. Dat omgooien is dus een behoorlijk werkje, en ik vraag me af of iemand hier een andere (simpeler) oplossing voor heeft?

[Joolee]

Je kunt ook bij het plaatsen van de sessies in de usertabel per sessie bijhouden wanneer deze voor het laatst is gebruikt. Niet handig maar wel mogelijk. Dat update je natuurlijk iedere pageview.

//Edit:
Als je iets comma seperated in een kolom gaat opslaan moet er eigenlijk al een alarmbel gaan rinkelen en moet je goed gaan nadenken of het niet beter is er een losse tabel voor te maken. Er zijn nog wel meer gegevens die je per sessie bij zou willen kunnen houden.
//Edit2:
Spuitelf

[ Voor 43% gewijzigd door Joolee op 20-07-2009 13:59 ]

[Voutloos]

SFB schreef op maandag 20 juli 2009 @ 13:54:
Een mogelijke oplossing die in me opkomt is een aparte tabel aanmaken voor de sessies

Dit zou uberhaupt je eerste gedachte moeten zijn zodra je anders iets comma separated wil opslaan.

SFB schreef op maandag 20 juli 2009 @ 13:54:
Dat omgooien is dus een behoorlijk werkje, en ik vraag me af of iemand hier een andere (simpeler) oplossing voor heeft?

Zonder code gezien te hebben durf ik te zeggen dat je je met een aparte tabel op de lange termijn werk bespaart.

[ Voor 37% gewijzigd door Voutloos op 20-07-2009 13:59 ]

[Janoz]

Met Voutloos. Het gaat hier om een duidelijke 1 op meer relatie en daar hoort nu eenmaal een apparte tabel met sessies bij met darin een FK naar users. Je hebt al moeten kloten met stringfuncties om met de puntkomma gescheiden versies te kunnen werken (een aparte tabel maakt het implementeren van in en uitloggen en het valideren een stuk makkelijker). Maar nu wil je per sessie ook nog wat meta data bijhouden (De meest voor de hand liggende optie lijkt mij namelijk om bij te houden per sessie wanneer hij voor het laatst gebruikt is en adhv die waarde bepalen welke sessies opgeruimd kunnen worden)

In het kort komt het er op neer dat je nu zo snel mogelijk de boel netjes moet inrichten. Elke workaround gaat je uiteindelijk meer tijd kosten dan de eenmalige investering van het ombouwen.

En, als je toch gaat kijken naar het ombouwen van je sessiemanagment, kijk dan vooral ook even hier naar.

[XiniX88]

sessies laten verlopen na 30 minuten... zet er een expire_date op (datetime + 1800 sec), deze verwijderen

DELETE * FROM sessions WHERE expire_date > NOW()

en inserten doe je:

INSERT of UPDATE expire_date = <?php echo time() + 1800 ?>

DELETE doe je altijd, INSERT doe je bij het aanmaken van een sessie, UPDATE doe je bij elke page hit.

[GlowMouse]

XiniX88 schreef op maandag 20 juli 2009 @ 14:49:
sessies laten verlopen na 30 minuten... zet er een expire_date op (datetime + 1800 sec), deze verwijderen

DELETE * FROM sessions WHERE expire_date > NOW()

en inserten doe je:

INSERT of UPDATE expire_date = <?php echo time() + 1800 ?>

DELETE doe je altijd, INSERT doe je bij het aanmaken van een sessie, UPDATE doe je bij elke page hit.

Hij wil juist dat sessies bewaard blijven

[Exception]

Misschien kun je een script maken dat alle verlopen sessies verwijderd. Deze zet je vervolgens in een cronjob en huppakee!

[cariolive23]

>> DELETE * FROM

Wat doet die * daar in de SQL? Die staat daar te zorgen voor een bug, gooi hem dan ook weg.

>> <?php echo time() + 1800 ?>
Wat is er mis met NOW() + INTERVAL 'gewenste interval' ? SQL is een taal en deze beschikt over vele (standaard) functies. Gebruik die dan ook, dat houdt het een beetje overzichtelijk en eenvoudig.

[XiniX88]

GlowMouse schreef op maandag 20 juli 2009 @ 14:52:
[...]

Hij wil juist dat sessies bewaard blijven

Je moet voor de belastingdienst ook je rekeninginfo 3 jaar bewaren, daarna mag het de prullenbak in. Een goede verloopdatum hier is dan daarom ook 3 jaar.

Bij deze sessies geld hetzelfde... ik laat ze in bovenstaand voorbeeld elke 30 minuten verlopen, maar dit kan ook 30 dagen zijn (zoals tweakers.net ook doet). Als de gebruiker na 30 dagen niet meer de site bezoekt, is de sessie dus idd verloren (bind de sessie dan wel aan het IP!)

Als de bezoeker dus wel binnen 30 dagen de site bezoekt, word de sessie weer verlengt met de huidige datum + 30 dagen. Zou volgensmij dus wel moeten werken dit.

Ik wil nog aan mn bovenstaande verhaal toevoegen dat het vaak gebeurd dat cookies weg zijn:

• Bij gebruik van een andere browser
• Herinstallatie PC
• Browsen in "safe mode"
• Weggooien van cookies (zoals je zelf al zei)
• Cookies hebben zelf ook een expire date, daarna worden ze ook verwijderd
• Etc. etc.

Dus het is zeker goed hier WEL rekening mee te houden!

cariolive23 schreef op maandag 20 juli 2009 @ 14:58:
>> DELETE * FROM

Wat doet die * daar in de SQL? Die staat daar te zorgen voor een bug, gooi hem dan ook weg.

>> <?php echo time() + 1800 ?>
Wat is er mis met NOW() + INTERVAL 'gewenste interval' ? SQL is een taal en deze beschikt over vele (standaard) functies. Gebruik die dan ook, dat houdt het een beetje overzichtelijk en eenvoudig.

Ik vind het HEEL leuk dat je de code afkat, ik geef hier een VOORBEELD en ga niet alles eindeloos uitwerken. Gaat om de gedachtenspinsel... dus niet zo zeiken

[ Voor 39% gewijzigd door XiniX88 op 20-07-2009 15:14 ]

[liledevil]

SFB schreef op maandag 20 juli 2009 @ 13:54:
Om dit mogelijk te maken, heb ik zoiets in de PHP staan:

1. Creëer een eigen (non-PHP) sessie id met een random string
2. Stop die in een cookie
3. Voeg die toe aan een veld in de database (bij de rij van die gebruiker), scheid daarin de id's d.m.v. een puntkomma.
4. Vergelijk bij het bezoeken van de pagina de sessie id in de cookie met de waarden in de database.
5. Als iemand uitlogt (via de knop) wordt de cookie verwijderd en de bijbehorende sessie id uit de database gehaald.

Als eerste heb ik even een paar vragen, puur om een beter beeld van de opzet te krijgen, eventuele kritische randjes in mijn vraagstelling moet je zien als opbouwende kritiek?

1. Waarom gebruik je een eigen sessieid ipv je PHP sessie id? Wat zijn de voor- en nadelen hiervan?
2. Welke expiredatum geef je aan de cookie's mee? Oftewel, hoelang wil je dat sessie blijven bestaan?
3. Hoe weet je de leeftijden van de opgeslagen sessies die zijn opgeslagen?
4. Heb je een indicatie hoelang het opzoeken van de juiste sessie-id nu duurt? En hoe schaalt dit naar het beoogde aantal gebruikers/sessies dat je wilt bijhouden in de site?
5. Zoals je aangeeft is het handmatig verwijderen van de cookies een optie om rekening mee te houden, maar ook eventuele privacy/security software kan deze op enige regelmaat verwijderen. Dit kan inhouden dat je snel oplopend aantal sessies kunt hebben, heb je al uitgerekend hoeveel sessies je database ontwerp dus maximaal kan bijhouden en hoe snel dit eventueel behaald kan worden.
6. Wat zijn je gedachten over error-handling in geval van bovenstaande, als er geen sessie meer kunnen worden toegevoegd, een sessie id maar half word toegevoegd etc.

Ik heb al reeds een reactie gelezen die het gebruik van een aparte sessie tabel impliceert, persoonlijk heeft dit ook vaak mijn voorkeur, maar denk dat je antwoorden op bovenstaande daar in jouw specifieke situatie meer uitsluitsel over kunnen geven.

[Tjolk]

liledevil schreef op maandag 20 juli 2009 @ 15:09:
[...]

Als eerste heb ik even een paar vragen, puur om een beter beeld van de opzet te krijgen, eventuele kritische randjes in mijn vraagstelling moet je zien als opbouwende kritiek?

Puntsgewijs:

1. Zo weet ik zeker dat de sessie niet gepikt kan worden. Niet per se nodig, maar goed.
2. 2 maanden.
3. Van de sessies in de database weet ik dat nu niet, van de sessies in de cookies kan ik dat uit de cookie vissen (die steeds ververst wordt)
4. Hoe bedoel je? Hoe lang PHP erover doet om het uit de database te trekken en te vergelijken met de cookie? Geen idee, maar het opbouwen van een complete pagina gaat sneller dan dat ik met mijn ogen kan knipperen. Nu heb ik idd nog niet heel veel gebruikers (vrij nieuwe site), dus wellicht dat het ooit nog wat lastiger wordt, maar voorlopig voorzie ik hier nog geen problemen.
5. Exact waar mijn vraag vandaan kwam (ik doelde met handmatig verwijderen slechts op een voorbeeld). In principe kunnen er enkele duizenden in opgeslagen worden, maar eens kom ik inderdaad een grens tegen. Die natuurlijk met wat goede wil weer op te rekken is, maar da's niet de meest handige methode zoals iedereen hier zal erkennen.
6. Daar begon ik vanmorgen dus over na te denken.

@allen: bedankt tot zover, mijn initiele gedachte lijkt hiermee bevestigd (al wacht ik nog ff wat reacties af natuurlijk).

[Janoz]

SFB schreef op maandag 20 juli 2009 @ 15:30:
[...]

Puntsgewijs:

• Zo weet ik zeker dat de sessie niet gepikt kan worden. Niet per se nodig, maar goed.

Niet waar. Beide oplossingen zijn even vatbaar voor session hijacking aangezien ze op hetzelfde principe gebaseerd zijn. De kans is zelfs erg groot dat je eigen implementatie minder goede keys genereerd waardoor je eigen implementatie eerder onveiliger is.

• Van de sessies in de database weet ik dat nu niet, van de sessies in de cookies kan ik dat uit de cookie vissen (die steeds ververst wordt)

Kortom, dat weet je dus niet aangezien je de inhoud van een cookie en uberhaupt het aanwezig blijven zijn van en cookie niet betrouwbaar is, maar dat was inderdaad net het probleem waarmee je dit topic startte.

• Hoe bedoel je? Hoe lang PHP erover doet om het uit de database te trekken en te vergelijken met de cookie? Geen idee, maar het opbouwen van een complete pagina gaat sneller dan dat ik met mijn ogen kan knipperen. Nu heb ik idd nog niet heel veel gebruikers (vrij nieuwe site), dus wellicht dat het ooit nog wat lastiger wordt, maar voorlopig voorzie ik hier nog geen problemen.

Bij een fikse lijst van gebruikers die elk ook nog eens behoorlijk wat sessies hebben zal de tijd die nodig is om de juiste sessie te zoeken behoorlijk oplopen aangezien je op geen enkele manier gebruik kunt maken van indexen en andere middelen om efficient met je data om te gaan. Maak maar eens een tabel met enkele duizenden gebruikers die elk meerdere sessies hebben en kijk dan of je site nog steeds zo vlot loopt.

[Patriot]

liledevil schreef op maandag 20 juli 2009 @ 15:09:Zoals je aangeeft is het handmatig verwijderen van de cookies een optie om rekening mee te houden, maar ook eventuele privacy/security software kan deze op enige regelmaat verwijderen. Dit kan inhouden dat je snel oplopend aantal sessies kunt hebben, heb je al uitgerekend hoeveel sessies je database ontwerp dus maximaal kan bijhouden en hoe snel dit eventueel behaald kan worden.

Ik denk niet dat dat zo'n probleem is. Als je weet bij welke gebruiker een sessie hoort kun je controleren of er al een lopende sessie voor die gebruiker is. Als dat het geval is kun je die gebruiken (of verwijderen en een nieuwe maken). Je hoeft dus nooit meer sessies dan gebruikers in je database te hebben.

[Janoz]

Als ik op twee plekken ingelogd ben (bijvoorbeeld op de computer thuis en op de computer op mijn werk) wil ik misschien wel helemaal niet dat ik op alle andere plekken uitgelogd wordt. Kijk ik bijvoorbeeld naar de sessies die ik nog heb lopen bij tweakers dan zie ik daar een stuk of 5. Werkplek, eigen desktop firefox, eigen desktop chrome, laptop thuis, laptop vrouw...

[liledevil]

Janoz schreef op maandag 20 juli 2009 @ 15:56:
Als ik op twee plekken ingelogd ben (bijvoorbeeld op de computer thuis en op de computer op mijn werk) wil ik misschien wel helemaal niet dat ik op alle andere plekken uitgelogd wordt. Kijk ik bijvoorbeeld naar de sessies die ik nog heb lopen bij tweakers dan zie ik daar een stuk of 5. Werkplek, eigen desktop firefox, eigen desktop chrome, laptop thuis, laptop vrouw...

QFT
Blijkbaar is daar ook al "rekening" mee gehouden door het al op de manier op te lossen zoals op dit moment word gedaan. Echter is vanuit het beheerdersperspectief gewoon een groot manco, je wilt op een gegeven moment oude sessies(lees ongebruikte/tombstone sessies) wel opruimen, maar met het huidige ontwerp gewoon geen mogelijkheid om goed te bepalen hoe, behalve "DELETE sessieid FROM users"(of andere SQL query wat dit veld bij iedereen leeghaalt, het is al een tijd geleden dat ik echt iets met SQL heb gedaan)

[Voutloos]

User:Session is een one to many relatie. Dus gewoon mooi in een tabelletje, en klaar. De rest is allemaal geneuzel in de marge.

[Patriot]

Janoz schreef op maandag 20 juli 2009 @ 15:56:
Als ik op twee plekken ingelogd ben (bijvoorbeeld op de computer thuis en op de computer op mijn werk) wil ik misschien wel helemaal niet dat ik op alle andere plekken uitgelogd wordt. Kijk ik bijvoorbeeld naar de sessies die ik nog heb lopen bij tweakers dan zie ik daar een stuk of 5. Werkplek, eigen desktop firefox, eigen desktop chrome, laptop thuis, laptop vrouw...

Dan kun je dus het oude sessie-id gebruiken, geen probleem hoor.

[Voutloos]

Neeheeee, want dan log je ook tegelijk uit, en je kan geen sessie specifieke features maken.

Allemaal geklets om niets, er is nog altijd geen goede reden gegeven om users maar tot 1 sessie te beperken en die enkel one to many relatie is hopelijk ook geen rocket science.

[ Voor 14% gewijzigd door Voutloos op 20-07-2009 16:19 ]