Session handling bzw. automatischer Logoff im Backend
Session handling bzw. automatischer Logoff im Backend
Das ist ein Verhalten, das wir von LEPTON mitgenommen haben und das WB (zumindest früher) nicht hat(te). Nach einer gewissen Zeit wird man aus dem Backend rausgeworfen, egal ob man noch aktiv ist oder nicht. Unter Umständen verliert man dadurch die letzten Änderungen.
Ich habe dazu mal einen Issue aufgemacht und würde gerne Eure Meinung hören.
https://github.com/BlackCatDevelopment/ ... issues/304
Ich habe dazu mal einen Issue aufgemacht und würde gerne Eure Meinung hören.
https://github.com/BlackCatDevelopment/ ... issues/304
My software never has bugs, it just develops random features.
If it’s not broken, keep fixing it until it is
If it’s not broken, keep fixing it until it is
Re: Session handling bzw. automatischer Logoff im Backend
Doch, WB hat das auch (und ich glaube schon immer). Das hat mich schon mindestens eine Tastatur und zwei Stunden Lebenszeit gekostet. Sprich, ich arbeite an einem Text oder Formular (mpForm) oder sonst irgendwas, klicke auf die Speichern-Schaltfläche unter dem betr. Abschnitt und statt der "Erfolgreich"-Meldung kommt die Login-Seite. Natürlich ist dann alles futsch. Arrrgh. Wäre cool, wenn BC so etwas nicht bringen würde.
Re: Session handling bzw. automatischer Logoff im Backend
Hm, ich habe dazu eine andere Aussage, aber was soll's, ich weiß es nicht. Ist ja auch egal.
Denkbar wäre folgende Umsetzung:
Wünschenswert, aber vermutlich nicht so einfach: Angenommen, man hat eine kurze Session Lebenszeit und für eine Aktion aus irgendeinem Grund (Mittagspause, Telefon, ...) länger gebraucht. Die Session würde also beendet. Dies wäre aber zu unterbinden, wenn Daten gesendet werden. Problem: Es ist nicht zu unterscheiden, ob der Zugriff noch von derselben Person kommt oder nicht. Um beim Szenario Mittagspause zu bleiben - es könnte ja sein, daß jemand die Abwesenheit des Benutzers ausnutzt, um irgendwelchen Mist zu speichern. Daher müßte man eigentlich die Daten zwischenspeichern, den Benutzer ausloggen, und beim Einloggen nachfragen, ob die letzte Änderung übernommen werden soll. Das ist aber wiederum modulabhängig.
Vielleicht könnte man das zweistufig angehen, erst obige "einfache" Umsetzung und das mit dem Zwischenspeichern für später aufheben. Wenn es denn überhaupt mit vertretbarem Aufwand machbar ist.
Denkbar wäre folgende Umsetzung:
- Grundsätzlich: Einstellbare Session-Lebensdauer 1)
- Session-Time wird bei jedem Zugriff zurückgesetzt, die Lebensdauer beginnt also von vorn
Wünschenswert, aber vermutlich nicht so einfach: Angenommen, man hat eine kurze Session Lebenszeit und für eine Aktion aus irgendeinem Grund (Mittagspause, Telefon, ...) länger gebraucht. Die Session würde also beendet. Dies wäre aber zu unterbinden, wenn Daten gesendet werden. Problem: Es ist nicht zu unterscheiden, ob der Zugriff noch von derselben Person kommt oder nicht. Um beim Szenario Mittagspause zu bleiben - es könnte ja sein, daß jemand die Abwesenheit des Benutzers ausnutzt, um irgendwelchen Mist zu speichern. Daher müßte man eigentlich die Daten zwischenspeichern, den Benutzer ausloggen, und beim Einloggen nachfragen, ob die letzte Änderung übernommen werden soll. Das ist aber wiederum modulabhängig.
Vielleicht könnte man das zweistufig angehen, erst obige "einfache" Umsetzung und das mit dem Zwischenspeichern für später aufheben. Wenn es denn überhaupt mit vertretbarem Aufwand machbar ist.
My software never has bugs, it just develops random features.
If it’s not broken, keep fixing it until it is
If it’s not broken, keep fixing it until it is
Re: Session handling bzw. automatischer Logoff im Backend
Hm? Von wem?ich habe dazu eine andere Aussage
<Rechthaberei>Ein Post im WB-Forum von (Trommelwirbel)... 2005!</Rechthaberei>
Naja, wurscht...
Ich verstehe davon nicht viel, aber ich glaube, die Session-Lebensdauer einzustellen, funktioniert insbesondere bei Shared-Hosting-Anbietern nicht so ohne weiteres. Sind das nicht serverseitig vorgegebene Werte?
Ideal wäre, wenn die Session aus welchen Gründen und zu welchem Zeitpunkt auch immer ungültig wird, ein modal window, das sich über den Eingabebereich legt und in dem ein entsprechender Hinweis sowie die Möglichkeit zur Eingabe der Anmeldedaten (Benutzername/Passwort) besteht - modal window, weil dann eventuell zuvor erfolgte und nicht gespeicherte Eingaben nicht verloren gehen.
Bei dem Tool OneFileCMS ist es ein simpler Countdown, der herunterzählt und zeigt, wann die Session ungültig wird. Auch das wäre hilfreicher, als überraschend ausgeknockt, pardon, ausgeloggt zu werden.
Wie macht Wordpress das eigentlich? Imho tritt da das Problem nicht auf.
Re: Session handling bzw. automatischer Logoff im Backend
Einem Kunden. Ist aber wirklich wurscht. Manchmal täuscht die Erinnerung halt, und ich hab so lang nicht mehr ernsthaft mit WB gearbeitet (nur um mal eben was zu testen), daß ich weder das eine noch das andere beschwören könnte.florian hat geschrieben:Hm? Von wem?ich habe dazu eine andere Aussage
Das ist korrekt, was die globale Session Lifetime angeht, die in der php.ini definiert ist. LEPTON und BC (eventuell auch WB) machen das über die Cookie Lifetime, die hartcodiert auf 3 Stunden eingestellt ist. Cookie weg, Session weg.florian hat geschrieben: Ich verstehe davon nicht viel, aber ich glaube, die Session-Lebensdauer einzustellen, funktioniert insbesondere bei Shared-Hosting-Anbietern nicht so ohne weiteres. Sind das nicht serverseitig vorgegebene Werte?
Die Idee mit dem Modal finde ich super, auch wenn ich derzeit noch nicht weiß, wie das zu implementieren ist. Aber das ist ja kein Hinderungsgrund. *g*
Vielleicht hat Wordpress ja keine Session Lifetime...
My software never has bugs, it just develops random features.
If it’s not broken, keep fixing it until it is
If it’s not broken, keep fixing it until it is
Re: Session handling bzw. automatischer Logoff im Backend
Ich hab jetzt mal in den Code von WB 2.8.3 geschaut und da gibt es keinen analogen Code. Demnach richtet sich die Session Lifetime bei WB wohl tatsächlich ausschließlich nach den Einstellungen in der php.ini. Vermutlich habt Ihr beide Recht, mein Kunde und Du. Halt je nachdem, wie die php.ini konfiguriert ist. Bei LEPTON und BC ist jedenfalls nach 3 Stunden Schluß, da kannst Du auf dem Server einstellen, was Du willst.
Ich habe mir jetzt folgendes überlegt: BC kann beim Erzeugen der Session die Einstellung aus der php.ini übernehmen - auslesen kann man sie ja. Den Cookie kann man dann analog konfigurieren, so daß Cookie Lifetime und Session Lifetime übereinstimmen.
Was nun den Ablauf der Session angeht, gibt es ein Problem: Die Session ist was serverseitiges, der Browser was clientseitiges, und HTTP ist ein statusloses Protokoll. Der Browser kriegt es gar nicht mit, wenn auf der Serverseite die Session abläuft, erst beim nächsten Zugriff. Und weil dann die Session weg ist, sind auch alle darin gespeicherten Daten (z.B. die Benutzerkennung) weg.
Ein Countdown erfordert Javascript, und ich bin mir nicht sicher, ob man dafür Ressourcen einsetzen will. Ich muß da mal nachforschen, auch wie das mit den Sessions eigentlich genau funktioniert.
Added in 2 hours 26 minutes 6 seconds:
So, einen Countdown hab ich schon mal. 5 Minuten vor dem Ende wechselt die Hintergrundfarbe auf rot. Die Session Lifetime wird aus der php.ini ausgelesen.
Added in 1 hour 31 minutes 16 seconds:
So, 30 Sekunden vor Ablauf der Session kommt jetzt auch schon ein netter Dialog. (Noch nicht übersetzt.)
Ich habe mir jetzt folgendes überlegt: BC kann beim Erzeugen der Session die Einstellung aus der php.ini übernehmen - auslesen kann man sie ja. Den Cookie kann man dann analog konfigurieren, so daß Cookie Lifetime und Session Lifetime übereinstimmen.
Was nun den Ablauf der Session angeht, gibt es ein Problem: Die Session ist was serverseitiges, der Browser was clientseitiges, und HTTP ist ein statusloses Protokoll. Der Browser kriegt es gar nicht mit, wenn auf der Serverseite die Session abläuft, erst beim nächsten Zugriff. Und weil dann die Session weg ist, sind auch alle darin gespeicherten Daten (z.B. die Benutzerkennung) weg.
Ein Countdown erfordert Javascript, und ich bin mir nicht sicher, ob man dafür Ressourcen einsetzen will. Ich muß da mal nachforschen, auch wie das mit den Sessions eigentlich genau funktioniert.
Added in 2 hours 26 minutes 6 seconds:
So, einen Countdown hab ich schon mal. 5 Minuten vor dem Ende wechselt die Hintergrundfarbe auf rot. Die Session Lifetime wird aus der php.ini ausgelesen.
Added in 1 hour 31 minutes 16 seconds:
So, 30 Sekunden vor Ablauf der Session kommt jetzt auch schon ein netter Dialog. (Noch nicht übersetzt.)
My software never has bugs, it just develops random features.
If it’s not broken, keep fixing it until it is
If it’s not broken, keep fixing it until it is
- creativecat
- Beiträge: 1431
- Registriert: Mi 6. Feb 2013, 12:41
- Kontaktdaten:
Re: Session handling bzw. automatischer Logoff im Backend
Sehr cool auch umgesetzt. Genau der richtige Platz dafür! Danke!
Re: Session handling bzw. automatischer Logoff im Backend
Es gibt noch ein paar Probleme, aber alles in allem bin ich schon recht weit. Ein Hauptproblem ist, daß man manchmal mit F5 auf die Seite zurückkommt, ohne sich erneut anmelden zu müssen, was ich nicht verstehe... Da im Hintergrund ein sauberer Logoff stattfindet. Scheint was mit dem Browsercache zu tun zu haben.
Hier noch ein Screenshot von dem Formular, wenn man den Countdown verpaßt hat. Der Hintergrund wird zu 90% abgedunkelt.
Hier noch ein Screenshot von dem Formular, wenn man den Countdown verpaßt hat. Der Hintergrund wird zu 90% abgedunkelt.
- Dateianhänge
-
- 2015-05-06 18_29_11-BlackCat CMS » Administration - START.png (22.42 KiB) 6397 mal betrachtet
My software never has bugs, it just develops random features.
If it’s not broken, keep fixing it until it is
If it’s not broken, keep fixing it until it is
Re: Session handling bzw. automatischer Logoff im Backend
Boarh! Sehr cool.
Re: Session handling bzw. automatischer Logoff im Backend
"Geht nicht - gibt's nicht!"
My software never has bugs, it just develops random features.
If it’s not broken, keep fixing it until it is
If it’s not broken, keep fixing it until it is