[php] sessie/login systeem

[Y0ur1]

Ik ben zelf bezig met een cms en ben aan het denken geslagen voor een goed login systeem en dat de users ingelogd kunnen blijven. Ik heb het React inlogsysteem een beetje bekeken en heb wat vraagjes.

- User komt op het forum (niet ingelogd)
- User krijgt een uniek ReactID
- User vult zijn gegevens in op de login page
- Username en password komen overeen, geslaagde login
- In de database in de sessie tabel(?) wordt het volgende opgeslagen:
• ReactID
• Ip (mits aangevinkt door de user)
• Lifetime?
• Ingelogd (Boolean)
- User is ingelogd
- User is lekker aan het gotten geslagen en op iedere pagina wordt zijn ReactID vergeleken met het record in de database.

Nu vraag ik me af, wordt het ReactID op iedere pagina gecheckt op het bestaan in de database? Het moet haast wel, want als ik het koekje verwijder of het ReactID verander ben ik uitgelogd, als ik het ReactID weer terug zet ben ik weer ingelogd.

Ook zie ik bij logout allemaal ReactID's staan, deze werken allemaal als ik de hash in de cookie zet.

Is het ReactID gewoon een sessie id die wordt gegenereerd door session_start() in php? En zie ik het goed dat die sessie hierna helemaal niet meer wordt gebruikt maar dat het in de database wordt opgeslagen?

alvast bedankt

[Verwijderd]

Waarom zou je nog een boolean 'ingelogged' opslaan? Als het record er is, is de user ingelogged.

Overigens denk ik niet dat je antwoord zult krijgen op je react vragen, daar react een commercieel product is en ik kan me zo voorstellen dat ze zo min mogelijk info als mogelijk willen verspreiden over het login-systeem (security by obscurity).

[Erkens]

[quote]Y0ur1 schreef op zondag 03 juli 2005 @ 23:23:
- In de database in de sessie tabel(?) wordt het volgende opgeslagen:
• ReactID
• Ip (mits aangevinkt door de user)
• Lifetime?
• Ingelogd (Boolean)

Je vergeet de userID, welke in het geval van (my)React staat op 0 als de user niet is ingelogt

Nu vraag ik me af, wordt het ReactID op iedere pagina gecheckt op het bestaan in de database? Het moet haast wel, want als ik het koekje verwijder of het ReactID verander ben ik uitgelogd, als ik het ReactID weer terug zet ben ik weer ingelogd.

natuurlijk wordt alles gechecked, daardoor kunnen de mensen die meer rechten hebben (modjes) ook meer knopjes krijgen en andere toeters en bellen. (vergeet ook de private fora niet zoals de HK)

Is het ReactID gewoon een sessie id die wordt gegenereerd voor session_start() in php? En zie ik het goed dat die sessie hierna helelmaal niet meer wordt gebruikt maar dat het in de database wordt opgeslagen?

Ik denk (weet bijna wel zeker) dat ze een eigen session handler hebben geschreven, maar je kan het idd vergelijken.

[crisp]

Het React sessiesysteem (en die van Tnet ook) zijn beide eigen session handlers en gebruiken dus niet de PHP sessie-functionaliteit. Een random sessie-id is eenvoudig te genereren (zie voorbeeld op php.net):

PHP:

$better_token = md5(uniqid(rand(), true));

In feite is de sessietabel niets meer dan:
- UserID (eventueel 0 voor een niet ingelogde gebruiker)
- SessieID

De rest van de functionaliteit die je wilt hebben (locken aan IP, Lifetime) kan extra velden vereisen

[Y0ur1]

Thanks voor de info, hier kan ik een boel mee, ik snap het een stuk beter. Niet dat ik verkeerde intensies heb hoor.

dus dat wordt zoiets:

PHP:

$hash = md5(uniqid(rand(), true));

if(!isset($_COOKIE['webintellectID']))
{
    setcookie("ReactID", $hash, time() + 3600 * 24 * 365);
}

wat bedoel je precies met een eigen session handle systeem? Wat zijn daar de voordelen van? Jullie gebruiken dus het standaard sessie verhaal van php totaal niet?

[ Voor 4% gewijzigd door Y0ur1 op 04-07-2005 00:14 ]

[c0deaddict]

Ik heb ook eigen session systeem geschreven. Het houd gewoon in dat je zelf checkt of een sessie geldig is, zelf code schrijft voor het aanmaken, verwijderen en updaten van sessies.

[Erkens]

maw je hebt volledige controle over alles wat er gebeurd en moet gebeuren, wat een enorm voordeel kan zijn, daarnaast kan je dingen doen die soms lastig zijn in bepaalde configuraties.
Ook kan je op deze manier een session locken op een IP waardoor session hijacking wat moeilijker wordt.

[Y0ur1]

Klinkt interessant allemaal, alleen waar sla je de variabelen op die je normaal zou declareren met $_SESSION['foo'] = "bar"?

[c0deaddict]

Die sla je ook op in de database, bij je session record

offtopic:
Erkens, coole sig, mooi gemaakt

[ Voor 37% gewijzigd door c0deaddict op 04-07-2005 00:38 ]

[Erkens]

Nee, de vraag moet zijn waar je je eigen session's opslaat
Je moet toch ergens die key's bijhouden.

Maar waarom heb je die variabele nodig? 9 van de 10x is het niet nuttig om die daar op te slaan. Maar mocht je het toch nodig hebben dan maak je een array die je serialized en dan opslaat bij die session key. Althans die methode zou ik gebruiken.

[Y0ur1]

Erkens schreef op maandag 04 juli 2005 @ 00:38:
Nee, de vraag moet zijn waar je je eigen session's opslaat
Je moet toch ergens die key's bijhouden.

Maar waarom heb je die variabele nodig? 9 van de 10x is het niet nuttig om die daar op te slaan. Maar mocht je het toch nodig hebben dan maak je een array die je serialized en dan opslaat bij die session key. Althans die methode zou ik gebruiken.

Als ik het nu zo bedenk is er bijna niks meer wat ik in die $_SESSION array zou willen zetten. Hooguit de username, maar die kan ik ook dmv een query uit de database halen.

[We Are Borg]

even een vraag wat dan bij mij op komt: waarom maak je je eigen sessie handler/creater/etc? Waaraan voldoet session() dan niet ?

[aex351]

We Are Borg schreef op maandag 04 juli 2005 @ 00:57:
even een vraag wat dan bij mij op komt: waarom maak je je eigen sessie handler/creater/etc? Waaraan voldoet session() dan niet ?

Ik denk dat ze bang zijn voor kleine foutjes in hun code waardoor je iemand sessie kan pakken, iets in die richting. Beetje paranoia .Maar er is infeite niets mis met sessies van php zelf, bespaart je ook veel tijd aangezien je anders eromheen loopt te bouwen.

[ Voor 15% gewijzigd door aex351 op 04-07-2005 01:04 ]

[Y0ur1]

aex351 schreef op maandag 04 juli 2005 @ 01:02:
[...]

Ik denk dat ze bang zijn voor kleine foutjes in hun code waardoor je iemand sessie kan pakken, iets in die richting. Beetje paranoia .Maar er is infeite niets mis met sessies van php zelf, bespaart je ook veel tijd aangezien je anders eromheen loopt te bouwen.

Sja ik zie niet zo veel verschil, met een gewone sessie heb je ook een cookie met het sessie id. Deze kan ook soms door een XSS hack naar een kwaadwillende worden gestuurd net zoals bij dit systeem. Mits je de IP check uit hebt staan blijft dat altijd een mogelijkheid naast dat je de cookie gewoon kunt kopieren.

[ Voor 10% gewijzigd door Y0ur1 op 04-07-2005 01:09 ]

[aex351]

Y0ur1 schreef op maandag 04 juli 2005 @ 01:08:
[...]


Sja ik zie niet zo veel verschil, met een gewone sessie heb je ook een cookie met het sessie id. Deze kan ook soms door een XSS hack naar een kwaadwillende worden gestuurd net zoals bij dit systeem. Mits je de IP check uit hebt staan blijft dat altijd een mogelijkheid naast dat je de cookie gewoon kunt kopieren.

sessies hebben een eigen systeem / functie binnen php. Met je eigen id's te creeeren kan je bijvoorbeeld bepaalde problemen oplossen omdat gebruikers bv verkeerde instellingen in php ofzo hebben. Een andere reden kan ik ook niet bedenken.

[Y0ur1]

aex351 schreef op maandag 04 juli 2005 @ 01:14:
[...]

sessies hebben een eigen systeem / functie binnen php. Met je eigen id's te creeeren kan je bijvoorbeeld bepaalde problemen oplossen omdat gebruikers bv verkeerde instellingen in php ofzo hebben. Een andere reden kan ik ook niet bedenken.

Sja maarja dat ben ik nog nooit tegen gekomen bij alle servers waar ik op heb gewerkt. Ik zou nog wel eens wat meer voordelen willen horen.

[Morax]

Y0ur1 schreef op maandag 04 juli 2005 @ 01:21:
[...]


Sja maarja dat ben ik nog nooit tegen gekomen bij alle servers waar ik op heb gewerkt. Ik zou nog wel eens wat meer voordelen willen horen.

Misschien het feit dat een sessie maar 20 mins duurt standaard (geloof ik), en dat als je je browser sluit je sessie weg is?

Wat ik overigens doe: Ik genereer een sessie_id en zet deze in een cookie. Als een user de site opvraagd, kijk ik of die cookie bestaat, en zo ja dan voer ik een query uit die de sessie ophaalt, en maak ik een join met de usertabel. Zijn er geen resultaten: user bestaat niet, en als er wel een resultaat is, heb je gelijk de gegevens van de user in je mysql results

[crisp]

PHP's sessies worden opgeslagen op het filesysteem, en daar kleven dus een aantal nadelen aan - bijvoorbeeld als je meerdere webservers hebt. Daarnaast biedt het opslaan van sessies in een eigen database nog meer voordelen zoals het kunnen bepalen van levensduur, makkelijk overzichten kunnen genereren en extra veiligheidsmaatregelen kunnen inbouwen (zoals locken op IP).
Uiteraard kan je dit met het PHP sessiesysteem ook wel doen, bijvoorbeeld door een custom session_handler te registreren, maar de ervaring leert dat het dan eenvoudiger is om de sessies zelf helemaal te beheren.

[supakeen]

Een eigen session class maken is niet veel werk en je kan er gewoon een stuk meer mee! Je kan bijvoorbeeld in de database bijhouden wat de laatste pagina is die een gebruiker bezocht heeft en om het uur laat je een cronjob alles controleren en wie langer dan een uur niet actief is geweest uit loggen.

Verder heb ik me overigens nooit verdiept in de sessions van PHP zelf en het altijd met eigen systemen afgehandeld dus ik weet niet 100% zeker of dit ook met de PHP sessions kan.

Maar het grootste punt (ongeveer 2x zo groot als een normaal punt) is dat je veel meer kan opslaan en veel meer controle over de bestaande sessies hebt.

[Erkens]

zmn schreef op maandag 04 juli 2005 @ 11:11:
Een eigen session class maken is niet veel werk en je kan er gewoon een stuk meer mee! Je kan bijvoorbeeld in de database bijhouden wat de laatste pagina is die een gebruiker bezocht heeft en om het uur laat je een cronjob alles controleren en wie langer dan een uur niet actief is geweest uit loggen.

Waarom zou je daar een cronjob voor gebruiken?
Zelf sla ik een einddatum/tijd op waarna de sessie is verlopen (welke ook wordt geupdate met elke request samen met het koekje) en op het moment dat deze is verlopen zal hij niet meer werken, wat opgemerkt wordt op het moment dat de gebruiker weer langskomt met die key (wat als het goed is dus nooit gebeurd vanwege de cookie)

[supakeen]

Erkens schreef op maandag 04 juli 2005 @ 11:15:
[...]

Waarom zou je daar een cronjob voor gebruiken?
Zelf sla ik een einddatum/tijd op waarna de sessie is verlopen (welke ook wordt geupdate met elke request samen met het koekje) en op het moment dat deze is verlopen zal hij niet meer werken, wat opgemerkt wordt op het moment dat de gebruiker weer langskomt met die key (wat als het goed is dus nooit gebeurd vanwege de cookie)

Dan houd je dus je sessies voor eeuwig in de tabel waardoor de tabel immens groot word, ik werk ook via jouw systeem maar met een cronjob loop ik na welke sessies verouderd zijn en kunnen worden verwijderd uit de tabel. Om de week (voorbeeld) kun je dan de tabel herstructureren zodat hij nooit zo immens groot word en je keys blijven kloppen.

Overigens heb ik jullie allemaal al een tijdje niet meer gezien

[ Voor 5% gewijzigd door supakeen op 04-07-2005 11:19 ]

[Sybr_E-N]

zmn schreef op maandag 04 juli 2005 @ 11:19:
[...]


Dan houd je dus je sessies voor eeuwig in de tabel waardoor de tabel immens groot word, ik werk ook via jouw systeem maar met een cronjob loop ik na welke sessies verouderd zijn en kunnen worden verwijderd uit de tabel. Om de week (voorbeeld) kun je dan de tabel herstructureren zodat hij nooit zo immens groot word en je keys blijven kloppen.

Overigens heb ik jullie allemaal al een tijdje niet meer gezien

Hangt er misschien een beetje vanaf hoeveel activiteit je hebt op de website, kwa aantal bezoekers enzo. Maar je kunt ook elke keer als er iemand lang komt de niet geldige sessions uit je db gooien. Daar kun je natuurlijk weer allemaal verschillende variaties van maken.

[Erkens]

mja, waarom zou je het verwijderen? Historische gegevens zijn handig voor statistieken etc.
Eventueel kan je de tabel een keer per maand ofzo opschonen als je dat zou willen
* Erkens verwijderd eigenlijk nooit gegevens uit zijn database, extreme uitzonderingen daar gelaten.

[supakeen]

Erkens schreef op maandag 04 juli 2005 @ 11:26:
mja, waarom zou je het verwijderen? Historische gegevens zijn handig voor statistieken etc.
Eventueel kan je de tabel een keer per maand ofzo opschonen als je dat zou willen
* Erkens verwijderd eigenlijk nooit gegevens uit zijn database, extreme uitzonderingen daar gelaten.

Bij mij is ook de enige uitzondering de table.sessions en mocht ik statistieken willen maken dan voer ik die berekeningen wel uit bij de loops van het verwijderingsscript en schrijf dat netjes weg in een xml sheet of iets dergelijks (niet alle gegevens dus, de resultaten van het totaal aantal sessies gehad e.d.)

[Y0ur1]

Het sessieID wat je maakt met:

PHP:

md5(uniqid(rand(), true));

moet er nog in de sessie tabel worden gekeken of die hash al bestaat? Theoretisch is het mogelijk dat iemand een hash krijgt toegewezen die al in de database staat... Of is dit te ver gezocht?

[crisp]

Y0ur1 schreef op maandag 04 juli 2005 @ 13:01:
Het sessieID wat je maakt met:

PHP:

md5(uniqid(rand(), true));

moet er nog in de sessie tabel worden gekeken of die hash al bestaat? Theoretisch is het mogelijk dat iemand een hash krijgt toegewezen die al in de database staat... Of is dit te ver gezocht?

Zekerheid voor alles, dus ja.
Als wij een tijdje geen cleanup doen op de GoT sessie-table dan staan daar zo ruim een miljoen sessies in...

[ripexx]

Als je een unique constraint of unique index (mysql) op deze tabel legt dan krijg je bij de insert een fout en die kan je afvangen. en dan een nieuwe ID genereren en weer weg schrijven. Of je kan het met een select doen. Als je deze indexeerd zou het in principe geen probleem moeten zijn met de preformance. In beide geval is et wel aan te bevlen om de unique index te leggen omdat je daarmee de integriteit van de data bewaakt. En nou niet gaan zeuren dat MySQL dat niet altijd helemaal volgens de regels doet

Maar de kans is relatief klein.

[Janoz]

Sybr_E-N schreef op maandag 04 juli 2005 @ 11:24:
[...]

Hangt er misschien een beetje vanaf hoeveel activiteit je hebt op de website, kwa aantal bezoekers enzo. Maar je kunt ook elke keer als er iemand lang komt de niet geldige sessions uit je db gooien. Daar kun je natuurlijk weer allemaal verschillende variaties van maken.

Doe dan maar gewoon een cronjob. Wanneer je garbage collecting laat doen doordat een bezoeker dit mogelijk triggered, dan wordt het garbage collecting proces onderdeel van het afhandelen van het request. Dit heeft 2 nadelen:
1. Extra executie tijd voor dat specefieke request
2. Garbage collecting afhankelijk van een bezoeker

Door een cronjob te gebruiken wordt het garbage collecten niet als onderdeel van een request uitgevoerd, en heb je ook meer controle over wanneer en hoe vaak het gebeurt.

[Erkens]

Maar niet altijd heb je de beschikking over een cronjob (of iets vergelijkbaars).

ripexx schreef op maandag 04 juli 2005 @ 13:11:
Als je deze indexeerd zou het in principe geen probleem moeten zijn met de preformance. In beide geval is et wel aan te bevlen om de unique index te leggen omdat je daarmee de integriteit van de data bewaakt. En nou niet gaan zeuren dat MySQL dat niet altijd helemaal volgens de regels doet

Als het goed is is die session_id de primary key van je tabel, iets anders is namelijk onzin
Maar waarom zou MySQL een unique index/key niet goed doen

[ripexx]

Erkens schreef op maandag 04 juli 2005 @ 13:21:
Maar niet altijd heb je de beschikking over een cronjob (of iets vergelijkbaars).
[...]
Als het goed is is die session_id de primary key van je tabel, iets anders is namelijk onzin
Maar waarom zou MySQL een unique index/key niet goed doen

* ripexx zit geloof ik een beetje te slapen Maar iets staat me bij dat de terug koppeling van een dubbele key een niet al te handige error geeft waardoor de afhandeling in de applicatie lastiger is.

[Erkens]

"Duplicate entry '4216455ceebbc3038bd0550c85b6a3bf' for key 1."
vind ik niet echt onduidelijk
hoe dan ook, je krijgt een error bij het inserten dus weet je dat het niet goed ging

[Dutchmega]

Ik heb juist voor een combinatie van sessions en database gekozen.

• Cookie bevat sessionID
• Session bevat ID van de row in de database

Checken of user ingelogd is en relevante data ophalen:

code:

SELECT users.status, sessions.sessionID, sessions.userID FROM sessions, users WHERE sessions.ip='' AND sessions.browserHash='' AND sessions.userID='' AND users.userID=sessions.userID

De session-lifetime staat verder op een week (tenzij "openbare computer" is aangevinkt) zodat de sessions niet voor eeuwig op de server staan.

Bij het inloggen wordt steeds een sessionID (db) genereert en gekeken of er al rows voorkomen met dezelfde ID. Zo niet, nieuwe inserten. En dan session plaatsen met de ID.

Dit systeem lijkt me wel redelijk veilig maar..