[sessions] ingelogd blijven

maandag 19 mei 2003 23:58

nope.

Verwijderd schreef op 19 mei 2003 @ 23:50:
[...]

meest logisch lijkt mij nog steeds.

1. iemand logt in
2. ==true -> genereer random code en schrijf die weg in de db met $id en wat je verder nog leuk vindt. Schrijf een cookie met dezelfde code.
3. user komt dag later terug. Kijk of issett($cookie) zoek in de db op welke code erbij hoort, register id en weer vrolijk doorgaan....lijkt mij!

Gebeurt op zijn minst dus 10-20 keer per dag en mensen komen nooit meer terug. Binnen de kortste keren zit jij met een ruimte gebrek op je server of een vervuilde database

Verwijderd schreef op 19 May 2003 @ 23:54:
en misschien bij elke aanroep van session_start timestamp updaten zodat je aantal ingelogde users online kan tellen? (in de laatste 5 minuten ofzo)

Precies hetzelfde probleem als eerder gemeld...

[ Voor 20% gewijzigd door Yo-han op 19-05-2003 23:57 . Reden: toevoeging ]

Acties:

maandag 19 mei 2003 23:59

dayoman schreef op 19 May 2003 @ 23:54:
[...]

Gebeurt op zijn minst dus 10-20 keer per dag en mensen komen nooit meer terug. Binnen de kortste keren zit jij met een ruimte gebrek op je server of een vervuilde database

Hiervoor bestaat zo iets als garbage collection. Elke keer als iemand binnen een sessie een pageview genereert, wordt de timestamp in de database op now() gezet. En tevens alle oudere sessies dan x dagen/minuten verwijderd.

PHP sessions werken precies zo.

Lekker woordenboek, als je niet eens weet dat vandalen met een 'n' is.

Acties:

Verwijderd

Topicstarter

dayoman schreef op 19 May 2003 @ 23:54:
[...]

Gebeurt op zijn minst dus 10-20 keer per dag en mensen komen nooit meer terug. Binnen de kortste keren zit jij met een ruimte gebrek op je server of een vervuilde database

[...]

Precies hetzelfde probleem als eerder gemeld...

ja niet iedere keer natuurlijk, eerst checken of die al een cookie heeft van een eerdere login. maar als je aantal users online wilt tellen zal je toch echt data moeten wegschrijven in een tabel.

dinsdag 20 mei 2003 00:01

Acties:

Verwijderd

Topicstarter

bigtree schreef op 19 May 2003 @ 23:58:
[...]
Hiervoor bestaat zo iets als garbage collection. Elke keer als iemand binnen een sessie een pageview genereert, wordt de timestamp in de database op now() gezet. En tevens alle oudere sessies dan x dagen/minuten verwijderd.

PHP sessions werken precies zo.

precies...lijkt me logisch. dat valt prima schoon te houden.

dinsdag 20 mei 2003 00:01

Acties:

dinsdag 20 mei 2003 00:05

nope.

bigtree schreef op 19 May 2003 @ 23:58:
[...]
Hiervoor bestaat zo iets als garbage collection. Elke keer als iemand binnen een sessie een pageview genereert, wordt de timestamp in de database op now() gezet. En tevens alle oudere sessies dan x dagen/minuten verwijderd.

PHP sessions werken precies zo.

Maar dan blijft dus alle overbodige info op jouw server staan! Met cookies is dit niet het geval... En als je de info te vroeg verwijderd, ben je weer niet klant vriendelijk bezig als de bezoeker terugkeerd.

* Yo-han vraagt zich af waarom tweakers dit dan nog niet gebruikte

[ Voor 7% gewijzigd door Yo-han op 20-05-2003 00:03 ]

Acties:

Verwijderd

Topicstarter

dayoman schreef op 20 mei 2003 @ 00:01:
[...]

Maar dan blijft dus alle overbodige info op jouw server staan! Met cookies is dit niet het geval... En als je de info te vroeg verwijderd, ben je weer niet klant vriendelijk bezig als de bezoeker terugkeerd.

/me vraagt zich af waarom tweakers dit dan nog niet gebruikte

waar wil jij dan op checken? alleen of de cookie bestaat client-side? Das nie safe, moet toch echt een vergelijking komen met de db. en waarom kan info niet een jaar in mijn db staan...

dinsdag 20 mei 2003 00:08

Acties:

dinsdag 20 mei 2003 00:10

nope.

Verwijderd schreef op 20 May 2003 @ 00:05:
[...]

waar wil jij dan op checken? alleen of de cookie bestaat client-side? Das nie safe, moet toch echt een vergelijking komen met de db. en waarom kan info niet een jaar in mijn db staan...

eeeh 3000 pageviews keer minimaal 1 bit... per maand of meer

ik weet wel waarom ik dat niet wil!

Is alleen handig met users waar je 100% zeker van bent dat ze vaker terug keren, dus alleen bij abonnementen of iets dergelijks zou ik zeggen.

Acties:

dinsdag 20 mei 2003 00:15

Als het gaat om het 'ingelogd blijven' zoals bij tweakers het geval is, heb je twee opties.

Ten eerste kan je aan de user-tabel een veld 'laatste_sessie_id' toevoegen. Op die manier blijft de hoeveelheid 'overbodige info' tot een minimum beperkt. In dat geval hoef je dus ook geen data te verwijderen na x dagen, omdat men makkelijk na een maand terug kan komen.

De tweede optie is om unieke sessies op te slaan in een sessie-tabel. Dit is vooral relevant als je wilt meten hoe vaak men inlogt.

Beide systemen zijn uit te breiden met een check op het ip-adres/browser etc. Dus dat een sessie automatisch vervalt als er een pageview vanaf een nieuw ip-adres komt, of met een andere browser. Ik denk niet dat ze bij tweakers een dergelijke check uitvoeren.

Lekker woordenboek, als je niet eens weet dat vandalen met een 'n' is.

Acties:

dinsdag 20 mei 2003 00:18

nope.

Tja ben bang dat dit toch een duidelijk geval van voorkeur is en erg aplicatie afhankelijk. Dus ga lekker pitten en wens jullie ook een goede nacht toe!

Acties:

Verwijderd

Topicstarter

dayoman schreef op 20 May 2003 @ 00:08:
[...]

eeeh 3000 pageviews keer minimaal 1 bit... per maand of meer
ik weet wel waarom ik dat niet wil!

Is alleen handig met users waar je 100% zeker van bent dat ze vaker terug keren, dus alleen bij abonnementen of iets dergelijks zou ik zeggen.

onzin elke id (waarmee je geregd bent) kan maar 1 maal voorkomen. 1000 geregistreerde gebruikers op je forum...maximaal 1000 entrys in je session table.

dinsdag 20 mei 2003 00:20

Acties:

Verwijderd

Topicstarter

bigtree schreef op 20 May 2003 @ 00:10:
Als het gaat om het 'ingelogd blijven' zoals bij tweakers het geval is, heb je twee opties.

Ten eerste kan je aan de user-tabel een veld 'laatste_sessie_id' toevoegen. Op die manier blijft de hoeveelheid 'overbodige info' tot een minimum beperkt. In dat geval hoef je dus ook geen data te verwijderen na x dagen, omdat men makkelijk na een maand terug kan komen.

De tweede optie is om unieke sessies op te slaan in een sessie-tabel. Dit is vooral relevant als je wilt meten hoe vaak men inlogt.

Beide systemen zijn uit te breiden met een check op het ip-adres/browser etc. Dus dat een sessie automatisch vervalt als er een pageview vanaf een nieuw ip-adres komt, of met een andere browser. Ik denk niet dat ze bij tweakers een dergelijke check uitvoeren.

en dit verhaal vat ik dus niet... hoe/waarmee check ik dan wie je bent als je na een maand terug komt? ( ip-adres/browser check lijkt me overbodig, kaan je ook een random key genereren)

dinsdag 20 mei 2003 00:23

Acties:

oOoOoOoOoOoOoOoOoOo

Ik doe het bijna het zelfde, alleen gooi ik een hash (md5 of sh2) van het wachtwoord in het cookie, hash staat ook in de db. Hierop controleren cookie een datum + x mee geven en klaar. Zo hoef je maar op 1 vaste waarde te checken (je hash) en of je cookie nog geldig is.

Dacht dat dit wel veilig is en een goede manier. Iemand hier misschien op- of aanmerkingen over?

dinsdag 20 mei 2003 00:27

Acties:

Verwijderd

Topicstarter

CrashOne schreef op 20 May 2003 @ 00:23:
Ik doe het bijna het zelfde, alleen gooi ik een hash (md5 of sh2) van het wachtwoord in het cookie, hash staat ook in de db. Hierop controleren cookie een datum + x mee geven en klaar. Zo hoef je maar op 1 vaste waarde te checken (je hash) en of je cookie nog geldig is.

Dacht dat dit wel veilig is en een goede manier. Iemand hier misschien op- of aanmerkingen over?

zoiets dacht ik dus ook, volgens mij is het safe.

dinsdag 20 mei 2003 00:29

Acties:

dinsdag 20 mei 2003 00:31

CrashOne schreef op 20 May 2003 @ 00:23:
Ik doe het bijna het zelfde, alleen gooi ik een hash (md5 of sh2) van het wachtwoord in het cookie, hash staat ook in de db. Hierop controleren cookie een datum + x mee geven en klaar. Zo hoef je maar op 1 vaste waarde te checken (je hash) en of je cookie nog geldig is.

Dacht dat dit wel veilig is en een goede manier. Iemand hier misschien op- of aanmerkingen over?

Je hebt neem ik aan ook een cookie met userid of iets dergelijks? Want wat als er twee mensen met hetzelfde wachtwoord in je database staan?

Lekker woordenboek, als je niet eens weet dat vandalen met een 'n' is.

Acties:

oOoOoOoOoOoOoOoOoOo

ja, idd... vergeten erbij te vermelden.

Denk dat dit wel de manier is.

dinsdag 20 mei 2003 00:32

Acties:

Verwijderd

Topicstarter

heb je gelijk in...waarom niet een random code generen van 10 karakters, wegschrijven in je cookie en in je table (alsmede de userid, timestamp etc). en die steeds vergelijken

dinsdag 20 mei 2003 00:35

Acties:

oOoOoOoOoOoOoOoOoOo

stel ik wil ingelogt zijn op meerdere pc's? Dan heb je een probleem, of je moet (te) veel data voor iedere user bij gaan houden.

dinsdag 20 mei 2003 00:36

Acties:

SyphOn

En als je nou gewoon de username en password codeert in een coockie en dan deze vergelijken met de user database? En dan in de userdatabse aangeven wanenerd e cookie voor het laatst is uitgelezen

dinsdag 20 mei 2003 00:38

Acties:

oOoOoOoOoOoOoOoOoOo

Volgens mij is mijn oplossing het makkelijkst en een hash is moeielijk terug te brengen naar het eigenlijke wachtwoord.

Maar ik ga slapen, lees het morgen wel!

dinsdag 20 mei 2003 00:45

Acties:

Verwijderd

Topicstarter

CrashOne schreef op 20 May 2003 @ 00:35:
stel ik wil ingelogt zijn op meerdere pc's? Dan heb je een probleem, of je moet (te) veel data voor iedere user bij gaan houden.

mmm...tja fuck... das ok weer waar!

passdw md5 in een cookie wegschrijven, ja tis niet slecht, plus een cookie met de id dus. Bestaan beide cookies vergelijk ze met de user tabel...Moet je iig zwaar je best doen om dat te brute forcen...

dinsdag 20 mei 2003 00:47

Acties:

Verwijderd

Topicstarter

aan de andere kant...GOT bewaart ook al die meuk

http://gathering.tweakers.net/forum/logout

staan 5 sessies nu van me open... hoe zit dat precies dan.

morgen weer verder idd...

[ Voor 30% gewijzigd door Verwijderd op 20-05-2003 00:54 ]

dinsdag 20 mei 2003 00:49

Acties:

SyphOn

Misschien kan Chem het ff uitleggen. Ik weet wel hoe het werkt denk ik maar ik kan het niet echt verwoorden

_{Ik ben dom en het is ook al laat.}

dinsdag 20 mei 2003 00:54

Acties:

dinsdag 20 mei 2003 00:56

Het hashen van een userid + pass en deze in een cookie stoppen heeft geen meerwaarde boven het genereren van een unieke, random session-id. Sterker nog, volgens mij is het beter om een random string van bijvoorbeeld 30 karakters te genereren (en deze bij een user op te slaan in je db EN als cookie weg te schrijven) dan om de UserID + Pass samen te hashen. En wel om drie redenen:

- Een hash is niet uniek, er kunnen in theorie twee verschillende users dezelfde hash hebben.
- Aangezien je geen userid apart in een cookie hebt zitten, moet je van alle users in je database een hash samenstellen om te achterhalen welke userid bij een sessie hoort.
- Een random string van 30 karakters is minder makkelijk te brute-forcen dan een hash van een password.

Kortom; als iemand aanvinkt dat hij onthouden moet worden bij het inloggen, genereer dan een random string van 30 karakters, sla deze op in het record in je user-tabel en schrijf de cookie weg naar de gebruiker. Bij elke pageview van deze gebruiker schrijf je de cookie weer een jaar vooruit.

Als iemand uitlogt, verwijder je de sessie uit het veld in je user-tabel.

En ja, dit geeft problemen als je op meerdere pc's onthouden wilt worden. In dat geval moet je een aparte sessie-tabel maken met sessie-id en userid.

Lekker woordenboek, als je niet eens weet dat vandalen met een 'n' is.

Acties:

SyphOn

ReactID = 2328d25812ee6695015c5d9452991462

^^
ff een voorbeeld.

bigtree,
Dit bedoel je dus met een random gegenereerd nummer? Of is dit de session id?

dinsdag 20 mei 2003 01:01

Acties: