nicht angemeldet
Einlesen aller Sessionen
Hallo
ist es möglich alle Sessionen einzulesen die mit session_register("user"); gesetzt wurden und noch gültig sind.
Mir geht es darum festzustellen welche User sich eingelogt haben.
Rolf Rössel
-
Moin!
ist es möglich alle Sessionen einzulesen die mit session_register("user"); gesetzt wurden und noch gültig sind.
Punkt 1: Benutze nicht mehr die Funktion session_register()! Speichere die Session-Informationen direkt in das Array $_SESSION rein.
Mir geht es darum festzustellen welche User sich eingelogt haben.
Punkt 2: Lies http://aktuell.de.selfhtml.org/artikel/programmiertechnik/useronline/index.htm.
- Sven Rautenberg
--
"Habe den Mut, dich deines eigenen Verstandes zu bedienen!" (Immanuel Kant) -
Hello Rössel,
ist es möglich alle Sessionen einzulesen die mit session_register("user"); gesetzt wurden und noch gültig sind.
Ich ahne, dass Du da was durcheinander bringst. Erstens sollte man bei PHP-Versionen >= 4.1.x die Funktionen session_register(), session_unregister(), usw. nicht mehr verwedendne und stattdessen die zur Session gehörenden Werte im Session-Array $_SESSION abspeichern.
Und außerdem hat hjder Benutzer eine eigene Sessiondatei, in dem seine Daten gespeichert werden. Wenn du festellen willst, welche User "Online" sind, also innerhalb einer bestimmten Zeit Ihre Sessiondaten bedient haben, dann musst Du das Last-Access und das Last_Change Datum der Sessiondateien anschauen. Also Session-Directory auslesen, und die Funktionen
http://de2.php.net/manual/de/function.filectime.php
http://de2.php.net/manual/de/function.fileatime.phpbenutzen. Dazu wäre es natürlich praktisch, die Sessiondateien vorher in ein eigenes Verzeichnis verlagert zu haben (php.ini)
Man kann das ganze auch mit einem intelligenten Login in eine Datenbank verlagern. Dort geht die Abfrage nach dem "Lastclick" viel schneller und unkomplizierter. Das Ganze hat sowieso nur statistischen Wert.
Liebe Grüße aus http://www.braunschweig.de
Tom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen-
Erstens sollte man bei PHP-Versionen >= 4.1.x die Funktionen session_register(), session_unregister(), usw. nicht mehr verwedendne und stattdessen die zur Session gehörenden Werte im Session-Array $_SESSION abspeichern.
Danke für den Hinweis, habe das Login auf Session-Array $_SESSION umgestellt. Werde das per Datenbank lösen, hatte nur gedacht es gäbe eine andere Lösung um festzustellen welcher User online ist.
-
Hello,
Danke für den Hinweis, habe das Login auf Session-Array $_SESSION umgestellt. Werde das per Datenbank lösen, hatte nur gedacht es gäbe eine andere Lösung um festzustellen welcher User online ist.
Das geht bei MySQL auch realtiv unkompliziert:
in der DB stehen z.B. Username, Passwort und Session_ID der zugeteilten Session.
Beim Login wird die Session gestartet und die SessionID in die DB geschrieben.
Das macht man einfach mit
"update login set session_id = $session_id where username = $username and password = $password"
Anschließend auswerten, ob genau ein Datensatz betroffen war, sonst zurück zum Login.
Und wenn dann eine Seite aufgerufen wird, und eine Session-ID mitgeliefert wird, dann wird einfach
"update login set lastclick=NULL where session_id = $session_id"
aufgerufen.
Das Feld lastclick in der Tabelle ist die erste Timestamp-Spalte, wird also bei MySQL automatisch bei Änderungen an der Tabelle geführt.
Wenn man nun ein Select über die Spalte lastclick macht
$time = [Referenzzeitraum in Sek]; also z.B. 900 für die letzten 15 Min.
select id_login, session_id from login where unix_timestamp(lastclick) > unix_timestamp()-$time;
dann erhält man sofort alle User, die in den letzten 15 Minuten aktiv waren.
Solltest Du eine Solche Anzeige planen, in der die Usernamen der "aktiven" angezeigt werden, würde ich auf jeden fall das Einverständnis der user vorher einholen. Man könnte das entweder zur Teilnahmebedingungen machen, oder in der User-Datei (login) ein entsprechendes Flag setzen, das der User selber manipulieren darf: Onlineanzeige JA/NEIN.
Liebe Grüße aus http://www.braunschweig.de
Tom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen-
Moin!
Beim Login wird die Session gestartet und die SessionID in die DB geschrieben.
Das macht man einfach mit
"update login set session_id = $session_id where username = $username and password = $password"
Anschließend auswerten, ob genau ein Datensatz betroffen war, sonst zurück zum Login.
DAS ist schlecht.
Punkt 1, dass da mehr als eine Spalte geändert wird, läßt sich durch einen Unique-Index auf den Usernamen ausschließen. Muß man aber natürlich tatsächlich so in der Tabelle anlegen. :)
Aber Punkt 2: Derselbe Benutzer will mit derselben Session-ID nochmal ein Login machen - das führt hier unweigerlich zu dem Problem, dass er nicht mehr reinkommt.
Sofern also bei so einem Fall die Session-ID auf der Folgeseite nicht geändert wird, hätte man hier ein Problem.
- Sven Rautenberg
--
"Habe den Mut, dich deines eigenen Verstandes zu bedienen!" (Immanuel Kant)-
Hello,
Aber Punkt 2: Derselbe Benutzer will mit derselben Session-ID nochmal ein Login machen - das führt hier unweigerlich zu dem Problem, dass er nicht mehr reinkommt.
Das ist auch erwünscht so, da in der Session seine sämtlichen offenen Vorgänge gestapelt sind. Da sollte er nicht einfach mit einer zweiten Anmeldung drin herumfuhrwerken. Wenn man Multilogin für User wünscht, benötigt man eine zusätzliche Tabelle und für jedes LOGIN euch eine getrennte Session oder hast Du schon mal gesehen, dass sich bei Linux zwei Prozesse eine PID teilen?
Beliebig kompliziert kann man ein solches System immer aufbauen.
Liebe Grüße aus http://www.braunschweig.de
Tom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen-
Moin!
Aber Punkt 2: Derselbe Benutzer will mit derselben Session-ID nochmal ein Login machen - das führt hier unweigerlich zu dem Problem, dass er nicht mehr reinkommt.
Das ist auch erwünscht so
Nein, ist es nicht. :)
So wie du es beschrieben hast, willst du eine Userdatenbank haben, die du mit
update login set session_id = $session_id where username = $username and password = $password
fütterst.
In Abhängigkeit von der Zahl der geänderten Spalten soll es dann weitergehen (Anzahl = 1) oder zurück zum Login (Anzahl = 0 - Anzahl > 1 wird durch Unique Username ausgeschlossen).
Das Problem ist: Was passiert, wenn die in der DB bereits gespeicherte Session-ID mit der Session-ID identisch ist, die vom aktuellen Anmeldevorgang herrührt?
Die Datenbank wird dies mutmaßlich erkennen und (MySQLs Standardverhalten) keinerlei Änderungen in der Zeile vornehmen, und somit "0" zurückgeben. Und damit landet der Benutzer wieder beim Login - es sei denn, in der Tabelle ändert sich ein existierender Timestamp. Das muß man dann natürlich dazusagen, weil es ein zwingendes, wichtiges Detail ist.
»»[...] da in der Session seine sämtlichen offenen Vorgänge gestapelt sind. Da sollte er nicht einfach mit einer zweiten Anmeldung drin herumfuhrwerken. Wenn man Multilogin für User wünscht, benötigt man eine zusätzliche Tabelle und für jedes LOGIN euch eine getrennte Session oder hast Du schon mal gesehen, dass sich bei Linux zwei Prozesse eine PID teilen?
Es ist absolut simpel, ein Multilogin in PHP zu realisieren. Einfach die klassischen Sessions benutzen. Fertig. Der Login erfolgt durch Abgleich mit der Userdatenbank, in der die Session-ID _nicht_ gespeichert wird, und schon werden alle je Session angefangenen und beendeten Statusdaten von PHP separat in jeweils einer eigenen $_SESSION-Dumpdatei gespeichert.
Dein Vorschlag hingegen ist so, wie du ihn bis hierhin vorgetragen hast, absolut ungeeignet, ein Multilogin zu verhindern. Denn wenn du einen Browser nimmst und dich einloggst, und dann einen zweiten Browser nimmst und dich nochmal einloggst (alternativ kann man auch nur einen einzigen Browser mit zwei Fenstern nehmen und Cookies ablehnen), dann wird das gelingen. Und mutmaßlich wird die erste Session bis zum Timeout aktiv sein und man damit arbeiten können.
Du hast zwei Dinge unterschlagen, die dafür zwingend zu implementieren sind:
1. Prüfung, ob für den Useraccount aktuell eine Session benutzt wird. Wenn ja, dann muß eine Rückfrage erfolgen, ob man diese Session killen will oder nicht.2. Abfrage auf jeder Seite, ob die aktuell verwendete Session des angemeldeten Users noch existieren darf, oder nicht.
Beliebig kompliziert kann man ein solches System immer aufbauen.
Und das muß man insbesondere, wenn man kein Multilogin will. Und es nervt den Benutzer durchaus. Ich kann mir als einziges Szenario für sowas eigentlich nur vorstellen, dass ein Lizenzgeber je Benutzeraccount ("concurrent users") abrechnet. In allen anderen Fällen sehe ich keinen Grund, ein Multilogin zu verhindern.
- Sven Rautenberg
--
"Habe den Mut, dich deines eigenen Verstandes zu bedienen!" (Immanuel Kant)
-
-
-
-
-