nicht angemeldet
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)