nicht angemeldet
Dir scheinen die Begriffe "requestbasiert" und "sessionbasiert" Probleme zu bereiten. Die haben hier nichts damit zu tun, dass man für beide Verfahren eine Session als Basis benötigt.
Ja, ich störe mich an den Begriffen, weil sie untauglich und verwirrend sind.
Ein Login ist üblicherweise sessionbasiert. Beim Login wird eine Session gestartet. Bei jedem Request wird serverseitig überprüft, ob unter der im Request angegeben Session-ID gespeichert ist, das eine Authentifizierung stattgefunden hat.
Die Gegenüberstellung von sessionbasiertem vs. requestbasiertem Login halte ich für Quatsch. Dies ist kein etablierter Begriff. Wenn ich danach google, finde ich nur dein Posting. -> Theoriefindung.
Dir scheinen die Begriffe "requestbasiert" und "sessionbasiert" Probleme zu bereiten. Die haben hier nichts damit zu tun, dass man für beide Verfahren eine Session als Basis benötigt.
"sessionbasiert":
Die authentifikation des Users findet nur einmal pro Session statt.
(...) Die Rechte des Users werden üblicherweise auf nur einmal pro Session geprüft und haben dann über die ganze Session Bestand.
"requestbasiert":
Bei jedem Request wird der Status des Users gegengeprüft.
Das ist unlogisch.
Die Authentifizierung besteht i.d.R. im Übermitteln von Username und Password. Das findet bei den üblichen Weblogins immer nur einmal statt.
Bei HTTP Basic Auth hingegen gibt es tatsächlich eine requestbasierte Authentifizierung. WEIL ES EBEN KEINE SESSION GIBT.
In DIESEM Sinne halte ich es für sinnvoll, von session- vs. requestbasierter Authentifizierung zu sprechen.
Wenn du jetzt sagst, dass beide Verfahren auf Sessions basieren, so ist das eine unbrauchbare und untypische Terminologie.
"sessionbasiert":
Ein Admin sieht nicht, wer "angemeldet" ist, da er i.d.R. die Sessionnummer eines Users nicht kennt.
Natürlich kann der Admin sehen, wer »angemeldet« ist (definiert als: welche User eine aktive Session haben). Dazu muss er nur alle Sessions durchgehen und nach dem Usernamen filtern. Das ist auch in PHP möglich, schließlich sind Sessions nur Dateien. Die Sessions in einer Datenbank zu speichern, macht den Zugriff nur einfacher. Es ist aber kein qualitativer Unterschied!
"requestbasiert":
Bei jedem Request wird der Status des Users gegengeprüft.
Das führt dann auch dazu, dass die allmeinen Rechte bei jedem Request erneut geprüft werden können.
Häh? Das geht natürlich auch bei ganz normalen Sessions, indem man prüft, ob der User gewisse Rechte hat. Das wird auch ständig getan. Dazu hat ein User meistens irgendwelche Capabilities, z.B. Lese- oder Schreibrechte auf einen gewissen Entity. Das löst man i.d.R. relational mit Rechtetabellen.
Ein Admin (oder wer auch immer) kann nun auch sehen, wer "angemeldet" ist.
Wie gesagt, das ist ein spezielles Feature, das mit Logins und Sessions erst einmal nichts zu tun hat.
Er kennet aber jtzt die Sessionnummer des Users und kann ihn auch jederzeit "rausschmeißen".
Das ist auch mit normalen Sessions möglich.
Das Big Picture ist: Es gibt tausende Arten, auf dem Server Sessions zu speichern. In Dateien, Datenbanken oder gar nicht (verschlüsselt im Cookie). Die meisten davon erlauben es ohne weiteres, die offenen Sessions für einen User zu finden. Dein Beispielcode erzeugt nur eine weitere Tabelle, die den Zugriff im Falle von dateibasierten Standard-PHP-Sessions vereinfacht.
Ich rede Dir im Übrigen auch nicht in deine mMn sehr qualifizierten Tipps zum Thema JavaScript rein ;-P
Ich hingegen rede dir in deine unqualifizierten Tipps zum Thema Sessions hinein.
Wie auch immer: Schreibe deinen Artikel und stelle ihn der breiteren Öffentlichkeit zur Diskussion.
Mathias
Der Martin
Matthias Apsel