Sessies en Cookies
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
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 -
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/
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.
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?
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