Sessies en Cookies

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

G Jansma

G Jansma

16/08/2018 09:57:19
Quote Anchor link
Hallo,

Ik ben bezig met een loginsysteem maar zie door de bomen het bos niet meer. Het systeem werkt met een database, maar ik loop telkens een beetje vast met de Sessie ID en Cookie. Ik heb al veel gelezen hier en op andere fora, maar ik krijg het maar niet helemaal voor elkaar hoe ik daar gebruik van moet maken.

- Loginsysteem met database (users en sessies)
- Aanvinken dat je ingelogd wil blijven
- Actief kunnen zijn op meerdere apparaten en browsers

Ik heb een database tabel waarin ik actieve sessies beheer. Als ik het goed begrijp moet ik na inloggen, uitloggen, en bij het wijzigen van gegevens de session_regenerate_id toepassen? De Sessie ID daarna wijzigen in de database en als cookie, zodat de oude - die waarmee de pagina is bezocht? - is verlopen?

Maar wat moet ik dan precies stallen als cookie? Gewoon de Sessie ID zoals die is? Het is zinloos om dat nog te hashen toch? En volstaat die cookie als enige, of is het ook nog handig om iets van een (gehashte) user_id, IP-adres, Browser of iets dergelijks als tweede cookie op te slaan als extra verificatie? Ik had gelezen dat IP-adres daar niet meer bruikbaar voor is ivm netwerken etc. Maar hoe doen jullie dat?

En hoe zorg je er dan voor dat iemand op meerdere apparaten en browsers op zijn account kan komen zonder in- en uitlogproblemen. Moet je dan per apparaat/browser een Sessie ID beheren in de database, en per apparaat een Cookie doen? Zodat de gebruiker bij terugkomst op het apparaat/browser nog steeds is ingelogd als hij tussentijds een ander heeft gebruikt.

Ik ga het hier even bij laten voor nu, maar ik hoop dat jullie me kunnen helpen. Ik heb me al een paar keer hier over gebogen, maar telkens er de brui aan gegeven door alle vragen die in me opkwamen, en ik dus door de bomen het bos niet meer zie. Maar ergens vind ik het ook wel leuk en een uitdaging om zelf een goed en veilig systeem te maken voor mijn gebruikers, waarvan ik zelf weet hoe het in elkaar zit. Ik hoop dat jullie me kunnen helpen.

Groet
 
PHP hulp

PHP hulp

29/03/2024 01:49:59
 
- Ariën  -
Beheerder

- Ariën -

16/08/2018 10:20:29
Quote Anchor link
In een ver verleden heb ik ooit eens een inlogsysteem gemaakt die bij het correct inloggen een cookie aanmaakte met een HashID en een UserID. In een checkLogin() functie werd vervolgens gecontroleerd of deze cookie-waardes overeen kwamen met wat er in de database stond. Ook was er een vinkje om een inlogsessie te koppelen aan een IP-adres. In dit geval zou het niet mogelijk zijn die sessie op een ander IP over te kunnen nemen via cookie-hijacking.

Het voordeel dat de sessies ook in de database stonden was dat je er ook makkelijke controle over had. Zo kon je jouw sessies op afstand uitloggen. Ideaal als je ergens vergeten was uit te loggen.

Het werkte niet met PHP-sessions.
Gewijzigd op 16/08/2018 10:25:13 door - Ariën -
 
G Jansma

G Jansma

16/08/2018 10:28:09
Quote Anchor link
Maar wat is nu gebruikelijk? Ik las in onderstaand topic dat je tegenwoordig de Sessie ID gebruikt? Maar hoe gebruik je die dan als cookie?

En hoe ga je dan om met gebruikers die actief zijn op meerdere browsers/apparaten?

https://www.phphulp.nl/php/forum/topic/session-id-metzonder-cookie/101484/last/
 
- Ariën  -
Beheerder

- Ariën -

16/08/2018 10:33:40
Quote Anchor link
In mijn systeem maakte ik die hash zelf.
Je kon op zoveel mogelijk plekken ingelogd zijn als je wou.

Ook met normale sessies en cookies kan dat. Die is gewoon aan een browser gekoppeld, de ene sessie/cookie heeft bij een tweede cookie/sessie geen weet van een eerdere cookie/sessie.
 
G Jansma

G Jansma

16/08/2018 10:47:30
Quote Anchor link
Oké, dat laatste lost dan al wat problemen op, ik wist niet helemaal of dat zo was. Op die manier heb je dus in de database X actieve sessies openstaan voor een gebruiker? Één voor elke browser/apparaat?

Ik heb alleen nog niet helemaal helder wat je - in een normaal/gebruikelijk systeem - nou precies als cookie moet opslaan? Gewoon direct de Sessie ID? En nog iets als verificatie?
 
- Ariën  -
Beheerder

- Ariën -

16/08/2018 11:13:17
Quote Anchor link
Een SessieID lijkt me voldoende.
 
Thomas van den Heuvel

Thomas van den Heuvel

16/08/2018 15:25:05
Quote Anchor link
Ik denk dat het voor de beeldvorming belangrijk is om eerst even wat dingen helder te krijgen. En dat begint met de definities van de verschillende concepten.

Een sessie is een middel om informatie aan de webserverkant over meerdere pagina-requests te onthouden. Dit is nodig omdat het HTTP protocol zelf stateless is, dat wil zeggen, als je van A naar B navigeert en je op B zit zal er normaal geen "historie" zijn van jouw bezoek aan A, dat is in principe al vergeten (maar je browser onthoudt dit). Alles wat je op A deed is dus kwijt. Vaak is er wel een wens om dingen te onthouden, zoals een taalvoorkeur, of je een enquete hebt ingevuld et cetera. Een aantal van die instellingen kan zonder enige impact aan de clientzijde worden onthouden, en dan zijn cookies hiertoe een geschikt middel. Betreft het echter informatie waar de website zelf de controle over dient te houden (gevoelige informatie zoals de identiteit van een gebruiker) dan schieten cookies tekort omdat deze manipuleerbaar zijn.

Een sessie op de webserver is (doorgaans, hier zijn ook volledige database-oplossingen voor) niets meer dan een bestandje waarin (geserialiseerd) informatie wordt opgeslagen. Dit wijkt dus eigenlijk niet zoveel af van een (clientside) cookie, maar heeft wel als verschil dat een gebruiker niet direct bij de inhoud van dit bestand kan. En dat opent interessante mogelijkheden. Net zoals cookies hebben deze bestanden een levensduur.

Het sessie-id is de (unieke) sleutel tot het (server side) sessie-bestand (of database-record(s), voor dit verdere relaas gaan we uit van bestanden, maar andere sessie-implementaties werken in wezen hetzelfde, of zouden dit in ieder geval moeten doen, aan de buitenkant is dit abstractie, je werkt alleen met $_SESSION). Dit sessie-id is verder "onbeschermd" in die zin dat als je het sessie-id weet, je in principe -zonder verdere voorzieningen- toegang hebt tot de sessie.

Een sessie-id kan in principe op twee manieren worden doorgegeven:
- via de URL
- via een cookie; kijk maar eens in de netwerktab van je browser, in de requests wordt een cookie-header meegestuurd met bijvoorbeeld het key-value paar PHPSESSID=<een hele hoop letters en cijfers>, dit laatste is je sessie-id en stemt overeen met de bestandsnaam van de sessie op de webserver in de directory waar de sessie-bestanden worden opgeslagen

De eerstgenoemde constructie kan handig zijn voor ontwikkelomgevingen maar leent zich niet echt voor de interwebs want tussenliggende verdeelpunten cachen mogelijk de requests en dan ligt je sessie-id dus op straat.

Uit het bovenstaande relaas komt het dus al een beetje naar voren dat een sessie-id alleen niet afdoende is als je sessies wilt gaan gebruiken voor authenticatie. Er zullen dus aanvullende controles uitgevoerd moeten worden om vast te stellen dat de sessie is van iemand die zegt dat deze van hem/haar is.

Een middel daartoe is het bijhouden van een IP-adres, die je bij kunt houden in de database. Afhankelijk van wat je precies wilt (eenzelfde gebruiker meerdere keren ingelogd vanaf verschillende devices via eenzelfde IP) zal dit je oplossing sturen. Als een apparaat van IP wisselt zul je een oplossing moeten verzinnen die niet afhankelijk is van een IP.

Los van deze hele discussie is er ook nog de vraag: wat zou ik allemaal bij moeten houden in de sessie zelf? Wat mij betreft hoef je in de sessie (qua usermanagement, natuurlijk ben je vrij om ook andere dingen te doen in je sessie zoals het tijdelijk opslaan van formulier-data enzo) eigenlijk alleen maar het user-id bij te houden. Het opslaan van rechten/rollen/privileges enzo zou ik niet in de sessie opnemen omdat dit soort informatie eigenlijk elke page-refresh geupdate dient te worden, als je elke keer de sessie moet bijwerken wordt dat misschien nogal bewerkelijk, vooral als dit soort zaken (van buitenaf) aangepast worden. Ik gebruik hiervoor in mijn applicatie een user object, die elke page-access opnieuw opgebouwd wordt.

Ook zou ik inzetten op een strategie waarbij het niet uitmaakt dat je sessie verloopt. Ik zou niet proberen sessies krampachtig in leven te houden want mogelijk blijft dan een sessie-id "te lang" in gebruik, wat mogelijk ook weer voor problemen zorgt. Daarbij verlopen sessies op een gegeven moment toch, dus kun je beter een mechanisme hebben dat dit ondervangt.

Dit is al een heleboel info zonder dat je nog een letter geprogrammeerd hebt. Maak jezelf vertrouwd met hoe sessies (en het HTTP protocol) werken, dan wordt vanzelf (zij het stap voor stap :)) na verloop van tijd duidelijk(er) hoe je e.e.a. zou moeten aanpakken.
Gewijzigd op 16/08/2018 15:28:37 door Thomas van den Heuvel
 



Overzicht Reageren

 
 

Om de gebruiksvriendelijkheid van onze website en diensten te optimaliseren maken wij gebruik van cookies. Deze cookies gebruiken wij voor functionaliteiten, analytische gegevens en marketing doeleinden. U vindt meer informatie in onze privacy statement.