Tutorial zu PHP Sessions

[Paeonia]

Hallo zusammen,

ist dieses tutorial noch aktuell und inhaltlich gut?

http://tut.php-quake.net/de/sessions.html

Wenn nicht, wäre ich für andere links dankbar.

Grüße von Paeonia

[suit]

ist dieses tutorial noch aktuell und inhaltlich gut?

Am Session-Handlung von PHP hat sich bei den Grundlagen nichts geändert - an das Tutorial kannst du dich immer noch halten.

[Paeonia]

Hallo,

Danke für Deine Antwort.

Gruß von Paeonia

[Paeonia]

Hi,

Am Session-Handlung von PHP hat sich bei den Grundlagen nichts geändert - an das Tutorial kannst du dich immer noch halten.

Gilt das auch für dieses tutorial?
http://tut.php-quake.net/de/login.html

Danke nochmal sagt paeonia

[hotti]

Hi,

Am Session-Handlung von PHP hat sich bei den Grundlagen nichts geändert - an das Tutorial kannst du dich immer noch halten.

Gilt das auch für dieses tutorial?
http://tut.php-quake.net/de/login.html

Oh je. Sicher geht das, ist aber viel zu umständlich und hat den Nachteil, dass der eigentliche "Login" clientseitig gespeichert ist.

Machs besser so:
-eine Tabelle für Benutzer, Passwort, email...
    => Für den Login-Prozess, Passwortprüfung

-eine andere Tabelle für den Login-Status, session-id, user, timestamp, benutzergruppe
    => Für die Abfrage, ob ein Benutzer eingeloggt ist

damit wird nur noch die session-id im cookie übertragen. Die Abfrage auf die zweite Tabelle liefert u.a. die Benutzergruppe, welche im Berechtigungs-System mit der Gruppe verglichen wird, die dem Request-URL zugeordnet ist.

Von Interesse ist auch der timestamp (Verfallsdatum, cleanup).

Hotti

[Paeonia]

Hi,

Oh je. Sicher geht das, ist aber viel zu umständlich und hat den
Nachteil, dass der eigentliche "Login" clientseitig gespeichert ist.

Soweit war ich in dem Tutorial noch nicht, das ist natürlich nicht der Sinn der Sache

Machs besser so:
-eine Tabelle für Benutzer, Passwort, email...
    => Für den Login-Prozess, Passwortprüfung

ok, hab ich

-eine andere Tabelle für den Login-Status, session-id, user, timestamp,
benutzergruppe

leg ich an

damit wird nur noch die session-id im cookie übertragen. Die Abfrage auf
die zweite Tabelle liefert u.a. die Benutzergruppe, welche im
Berechtigungs-System mit der Gruppe verglichen wird, die dem Request-URL
zugeordnet ist.

Das heißt für jeden Request, den ich auf den Server schicke (per AJAX, jqgrid) frage ich vorher ab, ob in der Tabelle Login-Status die session-id aktuell ist, für den user gültig und das Verfallsdatum < timestamp plus z.B. 30 minuten.

Clean up bedeutet jetzt genau was? Lösche alle Datensätze aus der Login-Status-Tabelle, deren Verfallsdatum erreicht ist (wie?), bzw. lösche den Datensatz über die Funktion Logout.

Ich habe bislang noch keinen soliden Login programmiert und versuche anhand von php.net und tutorials dieses Thema erlernen.

Danke für Deine weitere Hilfe sagt Paeonia

[hotti]

hi, danke der Nachfrage;

Das heißt für jeden Request, den ich auf den Server schicke (per AJAX, jqgrid) frage ich vorher ab, ob in der Tabelle Login-Status die session-id aktuell ist, für den user gültig und das Verfallsdatum < timestamp plus z.B. 30 minuten.

Aufgrund der Tatsache, dass die Session-ID (SID) weltweit eindeutig ist, darfst Du die SID als Primary Key in der Login-State-Table benennen. Zur Abfrage gehst Du einfach mit der SID da rein und bekommst z.B. user, group. Mehr brauchst Du eigentlich nicht, evntl. noch den timestamp (für den Zeitpunkt der Anmeldung).

Clean up bedeutet jetzt genau was? Lösche alle Datensätze aus der Login-Status-Tabelle, deren Verfallsdatum erreicht ist (wie?), bzw. lösche den Datensatz über die Funktion Logout.

Ganz genau! Cleanup ist auch ein Begriff aus der OOP, unmittelbar vor der Zerstörung eines Objekts wird die Destroy-Method aufgerufen, das gelegentlich wird auch als cleanup bezeichnet. Wenn Du mit OOP unterwegs bist, schreibe einfach ein Stück Code in die Destruktor-Methode, womit die Login-Tabelle von verfallenen Logins befreit wird ;)

Ich habe bislang noch keinen soliden Login programmiert und versuche anhand von php.net und tutorials dieses Thema erlernen.

Ich persönlich finde es sehr schade, dass Du das nicht mit Perl machst, ich bin mal so frech und poste ein Stück Code, was die Einfachheit zeigt:

  
sub login{  
	my $self = shift;  
	require Passfile; # Datei mit Passwort-Hashes  
	my $pass = Passfile->new($CFG->{passfile}) or do{  
		$self->errpush("Passfile not found");  
		return;  
	};  
	if($self->param('login')){  
		$self->ps(qw(user)); # ps() setzt Eingaben aus der Parameterliste in den STASH  
		my ($error, $username, $level) = $pass->usercheck($self->param('user'), $self->param('pass'));  
		if($error){  
			$self->{STASH}{mesg} = $error;  
			$self->invalid; # setzt class="err" (Schrift wird rot)  
			return;  
		}  
		else{  
			# schreibe LOGINTAB und redirekt  
			$self->{LOGINTAB}{$self->{SID}} = {  
					user => $username,  
					ts => time,  
					level => $level,  
			};  
			$self->{REDIRECT} = $self->{URL};  
		}  
	}  
	elsif($self->param('logout')){  
		delete $self->{LOGINTAB}{$self->{SID}};  
		$self->{REDIRECT} = $self->{URL};  
	}  
	else{$self->errpush('Unbekannter Parameter')}  
}  

Obwohl: Diese Überschaubarkeit ist nicht unbedingt Perl-spezifisch, die kannst Du vielleicht auch mit PHP hinbekommen ;)

Hotti

[Matti Mäkitalo]

Hi,

Aufgrund der Tatsache, dass die Session-ID (SID) weltweit eindeutig ist, darfst Du die SID als Primary Key in der Login-State-Table benennen. Zur Abfrage gehst Du einfach mit der SID da rein und bekommst z.B. user, group. Mehr brauchst Du eigentlich nicht, evntl. noch den timestamp (für den Zeitpunkt der Anmeldung).

ich würde einfach $_SESSION nutzen.
Ggf. das Speicher-Backend austauschen, aber nicht zu einem DBMS, sondern zu memcached. Solche flüchtigen Daten eignen sich IMHO nicht so gut für ein RDBMS.

Bis die Tage,
Matti

[hotti]

hi,

Aufgrund der Tatsache, dass die Session-ID (SID) weltweit eindeutig ist, darfst Du die SID als Primary Key in der Login-State-Table benennen. Zur Abfrage gehst Du einfach mit der SID da rein und bekommst z.B. user, group. Mehr brauchst Du eigentlich nicht, evntl. noch den timestamp (für den Zeitpunkt der Anmeldung).

ich würde einfach $_SESSION nutzen.

Ja, sehr gut. So ähnlich läuft das auch bei mir, mein Response-Objekt hat als Attribut eine Referenz auf die Login-Tabelle.

Guck mal

Ggf. das Speicher-Backend austauschen, aber nicht zu einem DBMS, sondern zu memcached. Solche flüchtigen Daten eignen sich IMHO nicht so gut für ein RDBMS.

Das ist auch ne gute Idee. Obwohl: Im Speicher lümmelt sich das so oder so ;)
Aber der Zugriff in den MEMCache geht schneller, da haste scho Recht!

Je nach Server gibts auch andere Möglichkeiten, z.B. mod_perl

Hotti

[dedlfix]

Tach!

[...] an das Tutorial kannst du dich immer noch halten.
Gilt das auch für dieses tutorial?
http://tut.php-quake.net/de/login.html

Ich habe es nur überflogen und mir nicht jedes Detail angesehen. Es ist sehr umfangreich, vor allem auch deshalb, weil es nicht einfach eine Schönwetter-Geradeausdurch-Version eines Login zeigt, sondern sehr um Fehlerbehandlung bemüht ist. Diesen Aspekt vernachlässigen leider viele Tutorials der Einfachheit zuliebe. Allerdings ist es vom Sicherheitsstandpunkt nicht wesentlich besser als eine HTTP-Authentication oder ein Session-ID-Cookie. Bei HTTP-Authentication wird vom Browser bei jedem Request Nutzername und Passwort oftmals unverschlüsselt übertragen. Im Tutorial wird das Passwort im Klartext nur einmal beim Formularausfüllen übertragen. Anschließend wird die User-ID und ein Passwort-Hash in einem Cookie abgelegt, und der wird bei jedem Request mitgesendet. Der Hash bringt gegenüber der Serveranwendung keinen Sicherheitsgewinn, denn wenn ich User-ID und Passwort-Hash kenne, kann ich auch ohne Kenntnis des Klartextes einen Request erzeugen, den der Server als angemeldeten User erkennt. Mit weniger Aufwand und gleicher Sicherheit kann man auch die Variante nehmen, bei der der Client nur eine Session-ID mitbringen muss. In den Session-Daten steht dann, ob der User angemeldet ist oder nicht beziehungsweise seine zur Anmeldung notwendigen Daten, wenn bei jedem Request die Authentisierung gegen das DBMS erneut geprüft werden soll.

dedlfix.

[Paeonia]

Hi,

Mit weniger Aufwand und gleicher Sicherheit kann man auch die Variante
nehmen, bei der der Client nur eine Session-ID mitbringen muss. In den
Session-Daten steht dann, ob der User angemeldet ist oder nicht
beziehungsweise seine zur Anmeldung notwendigen Daten, wenn bei jedem
Request die Authentisierung gegen das DBMS erneut geprüft werden soll.

Danke erst mal, aus dem was Du und Hotti und das Tutorial mir sagen wollen, werde ich übers Wochenende einen Login bauen. Ich würde mich freuen, wenn ich das dann nochmal posten könnte in den wichtigsten Teilen, so dass ich Rückmeldung bekomme, ob das passt.

Danke sagt Paeonia.

[dedlfix]

Tach!

Danke erst mal, aus dem was Du und Hotti und das Tutorial mir sagen wollen, werde ich übers Wochenende einen Login bauen. Ich würde mich freuen, wenn ich das dann nochmal posten könnte in den wichtigsten Teilen, so dass ich Rückmeldung bekomme, ob das passt.

Es gibt verschiedene Varianten, wie man so ein Login realisieren kann.

Die einfachste ist, nach dem Übermitteln der Anmeldedaten durch den Client prüft man, ob diese zu einem Login passen und schreibt die Statusinformation, dass der Anwender eingeloggt ist nebst weiteren Daten, die zur Prüfung von Berechtigungen benötigt werden, in die Session. Bei weiteren Requests prüfst du nur die Session-Daten. Einfacher geht es (vermutlich) nicht, aber diese Art bringt natürlich auch ein paar Nachteile mit sich. Du kannst zwar im Bedarfsfall eine Anmeldesperre oder Berechtigungsänderungen im DBMS hinterlegen, aber sie wirken sich nicht auf die in der Session gespeicherten Daten aus. Wenn du jedoch eine sofortige Auswirkung benötigst, dann müsstest du alle Session-Dateien nach diesem User durchflöhen und die Änderungen einpflegen, die Session-Datei löschen und damit auch eine Zwangsabmeldung vornehmen oder irgendwas anderes geeignetes durchführen.

Eine weitere Variante ist, für jeden Request erneut die Anmeldedaten und auch die Berechtigungen gegen die Stammdaten zu prüfen, was immer mindestens einen Datenbankzugriff benötigt. Aber Änderungen wirken sich sofort aus. Diese Vorgehensweise braucht man auch bei HTTP-Authentication und Implementierungen ohne Session und damit ohne Cookies.

Zwischen diesen beiden Varianten gibt es noch Zwischenstufen, bei denen manche Daten in der Session vorgehalten werden und andere live abgefragt werden. Was konkret du nun einsetzen solltest hängt natürlich stark vom Anwendungsfall und den damit einhergehenden Bedingungen ab.

dedlfix.