PHP-Scripte PHP-Tutorials PHP-Jobs und vieles mehr

PHP-Scripte PHP-Tutorials PHP-Jobs und vieles mehr (https://www.php-resource.de/forum/)
-   PHP Developer Forum (https://www.php-resource.de/forum/php-developer-forum/)
-   -   Session Lifetime (https://www.php-resource.de/forum/php-developer-forum/79310-session-lifetime.html)

Hirnhamster 15-12-2006 18:13

Session Lifetime
 
Hey!

Ich habe auf meiner Seite ein Login-System, dass auf Sessions basiert.
Es gibt eine zentrale index.php in die alle anderen Seiten includiert werden, deshalb steht am Anfang dieser Datei session_start, sodass es auf jeden aufgerufenen Seite am Anfang steht.

Damit die User sich nicht nach jedem Schließes des Browser und / oder nach längerer Inaktivität neu einloggen müssen, setze ich die Lifetime der Session und die des Cookies (falls der User Cookies aktiviert hat) auf ein Jahr.

PHP-Code:

    ini_set('session.cookie_lifetime'3600*24*365);
    
ini_set('session.gc_maxlifetime'3600*24*365); 

Nun ist es aber so, dass sich ja nicht jeder Nutzer, der die Seite besucht, registriert und einloggt. Die Session wird aber auf jeden Fall gestartet.
Nun habe ich mal in meinen tmp Ordner reingeschaut und darin waren Unmengen von Session-Dateien, von denen fast alle leer waren. Da ich aber die Lifetime auf ein Jahr gesetzt habe, räumt die garbage collection natürlich nicht auf.

Jetzt steh ich vor dem Problem, dass ich die Lifetime einer Session nur dann auf ein Jahr setzen will, wenn sich der User auch tatsächlich einloggt.
Da session_start auf jeden Fall am Anfang jeden Scriptes aufgerufen ist, wurde die Session ja bereits gestartet, wenn der User auch nur die Seite aufruft.

Meine Frage ist nun, ob ich das Problem irgendwie umgehen kann, also die Lifetime der Session nur dann auf ein Jahr setzen kann, wenn sich der User auch wirklich einloggt.

ghostgambler 15-12-2006 19:19

Re: Session Lifetime
 
Ich würde ein vernünftiges Auto-Login-System implementieren, d.h. du speicherst im Cookie (dessen Laufzeit du beliebig festlegen kannst) einen String, anhand dessen du in der Datenbank den User finden kannst, und wenn der Cookie gesetzt ist, loggst du den User beim Betreten der Website ein. Und die beiden ini_set-Zeilen wieder raus

Ist zwar eine hübsche Idee die Session aktiv zu lassen, aber nicht wirklich hübsch praktikabel

3DMax 15-12-2006 19:59

Re: Re: Session Lifetime
 
Zitat:

Original geschrieben von ghostgambler
d.h. du speicherst im Cookie einen String, anhand dessen du in der Datenbank den User finden kannst
sorry, dass ich mich jetzt einklinke.
aber wie wird soetwas allgemein gehandhabt? also was bedeutet in diesem fall "String" - wie setzt der sich zusammen bzw. wie wird er generiert?

combie 16-12-2006 02:28

PHP-Code:

$string md5('Salz und '.rand()); 

Sowas reicht meist als Markierung.
Ist im Grunde auch egal, Hauptsache eindeutig und
schwer zu erraten.

3DMax 16-12-2006 03:24

Zitat:

Original geschrieben von combie
Sowas reicht meist als Markierung.
Ist im Grunde auch egal, Hauptsache eindeutig und
schwer zu erraten.
ja klar, passwörter kann man "salzen", aber man muss später auch aus dem cookie-"String" auf einen konkreten account schließen können.
selbst "gesalzte" passwörter können doppelt vorkommen (theoretisch).

ich glaube, ich hab's:
md5-(password mit username als salt) und im cookie noch den username und/oder user_id hinterlegen.
müsste passen - oder?

combie 16-12-2006 03:37

Der username sollte nicht im Cookie gespeichert werden..!
Das mit dem Salz ist auch relativ unwichtig..
Es dient nur dazu, den md5 String schwerer "vorauszusagen"
du brauchst halt irgendwas, was zufällig genug ist..

So...
Du hast sowieso eine usertabelle mit
ID | nick | email | passwort | usw

Du brauchst zusätzlich eine Tabelle: dauerlogin
dauerloginkey | userid | timestamp

Im Cookie speicherst du dann den dauerloginkey
Damit die Tabelle nicht aus dem Ruder läuft,
solltest du regelmäßig veraltete Einträge löschen.
Wenn dauerloginkey unique-index gesetzt ist, hat sich das
mit den Doppelvergaben auch erledigt..

3DMax 16-12-2006 04:05

ok, db-spalte, dachte ich mir schon.

Zitat:

Original geschrieben von combie
Der username sollte nicht im Cookie gespeichert werden..!
weil du schon mit dem ausrufezeichen ausdrücken möchtest, dass es potentiell unsicher ist (in diesem fall den benutzernamen zu speichern):

ich frage mich, ob man überhaupt einen auto-login zulassen sollte?
die sicherheitslücke internetcafe fällt mir da z.b. spontan ein, ein klick auf [] automatisch einloggen (bild-leser, und nicht nur diese, klicken auf alles mögliche) und alle nachfolger haben zugriff auf meinen account - toll.

combie 16-12-2006 12:52

Wenn der User im Internetcafe dieses Häkchen setzt, ist er selber Schuld..

Aber du hast Recht!
Man sollte das Autologin keinesfalls zum Standard erheben..!!

Hirnhamster 16-12-2006 22:03

Naja Problem ist, dass ich die Daten der Session weiterhin brauche, da dort nich nur Username und Rechte drin stehen.

ich hab's jetzt so gelöst, dass ich das Sessions System selbständig über eine DB verwalte. Damit hab ich ne bessere Kontrolle über die Lifetime der Session und kann sie für den Benutzer einzeln beliebig anpassen.

Grundlage war dieses Tutorial

combie 17-12-2006 13:34

Ein klares Wort?

Ja dann: Ich halte nix davon !!
1. Du versuchst Sessions für irgendwas zu missbrauchen, wofür sie nicht gedacht sind
2. nicht auf jedem System darfst du einen eigenen Session Handler stetzen
4. nur kurzlebige Daten in Session halten!
3. Langfristige Datenhaltung sollte in der DB stattfinden

ghostgambler 17-12-2006 17:22

Zitat:

Original geschrieben von combie
1. Du versuchst Sessions für irgendwas zu missbrauchen, wofür sie nicht gedacht sind
Steht wo?

Zitat:

2. nicht auf jedem System darfst du einen eigenen Session Handler stetzen
Wüsste nicht wieso das nicht erlaubt sein sollte. Wenn der Hoster die Funktion deaktiviert hat -> Hoster wechseln

Zitat:

4. nur kurzlebige Daten in Session halten!
3. Langfristige Datenhaltung sollte in der DB stattfinden

Wieso?

Es ist nicht die übliche Verwendung von Sessions, aber ob jetzt ein session-cookie/session oder ein autolog-cookie/der entsprechende Datensatz, auf dem Server "offen" verbleibt, dürfte ziemlich Jacke wie Hose sein ... zumindest bin ich nach 2 Tagen überlegen über diesen Thread zu dem Schluss gekommen

combie 17-12-2006 20:52

Je länger die Sessions halten, desto mehr offene Sessions werden gehalten..
Je mehr offene Sessions, desto größer die Chance zur versehndlichen Übernahme..

Bei einer Lebenzeit von min 24 Minuten(Standard) ist die Wahrscheinlichkeit geringer, als wenn man das auf 1 Jahr ausdehnt...

Klar könnte man einen fürchterlichen Bug im Konzept, dadurch versuchen auszubügeln, daß man die Sessionverwaltung aufbläht...

Teil der Grundidee von Sitzungen, ist es ja gerade, daß diese auch mal enden.. und das Schließen des Browsers, ist doch der passende Zeitpunkt, warum davon abweichen und dieses wunderschöne Konzept unterlaufen..?:)
:D Wenn es dem Esel zu gut geht, dann geht er aufs Glatteis :D

Ps:
Ich halte nicht viel von Autologin Systemen, bequem, Ja, das ist auch schon das schönste daran..

ghostgambler 17-12-2006 21:14

Zitat:

Original geschrieben von combie
Je länger die Sessions halten, desto mehr offene Sessions werden gehalten..
Je mehr offene Sessions, desto größer die Chance zur versehndlichen Übernahme..

Das gleiche Problem hat man bei der Auto-Login-ID auch, ist also das gleich in grün

combie 17-12-2006 21:24

Genau!
Ein riesen Sicherheitsloch!
Aber das kann man auch haben, ohne das arme Sessionhandlig umzukrempeln :D

ghostgambler 17-12-2006 22:17

Zitat:

Original geschrieben von combie
Genau!
Ein riesen Sicherheitsloch!
Aber das kann man auch haben, ohne das arme Sessionhandlig umzukrempeln :D

Du glaubst also, dass ein 32^16 Zufallswert ein riesen Sicherheitsloch ist?
Ich finde das für reines BruteForce schon zu zeitaufwendig...


Alle Zeitangaben in WEZ +2. Es ist jetzt 12:05 Uhr.

Powered by vBulletin® Version 3.8.2 (Deutsch)
Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.
Search Engine Friendly URLs by vBSEO 3.3.0
[c] ebiz-consult GmbH & Co. KG