Login im Frontend führt zu Logout im Backend und umgekehrt

[Mynyx]

Wenn man sich in einem Browser im Backend einloggt und anschließend im Frontend, ist man im Backend ausgeloggt. Loggt man sich anschließend wieder im Backend ein, ist man im Frontend ausgeloggt.

Ursache ist wohl, dass die Session ID bei Login regeneriert wird (https://github.com/contao/core/blob/master/system/modules/core/library/Contao/User.php#L435), jedoch das Login-Cookie auf der Session ID basiert (https://github.com/contao/core/blob/master/system/modules/core/library/Contao/User.php#L245-L249).

[aschempp]

I hate to be right 😭

Source: #8425
@discordier @Toflar

[leofeyer]

Das ist durchaus das beabsichtigte Verhalten. Wenn Du im BE angemeldet bist, musst Du die FE-Vorschau verwenden, um Benutzeranmeldungen zu simulieren. Andernfalls wirst Du wie bereits bemerkt komplett abgemeldet.

@aschempp Das hat nichts mit der Änderung aus #8425 zu tun. War schon immer so.

[Mynyx]

Nein, wenn man https://github.com/contao/core/blob/master/system/modules/core/library/Contao/User.php#L435 auskommentiert, tritt das Problem nicht auf.

Weiterhin können normalen BE-Benutzer hierzu auch nicht die FE-Vorschau verwenden, da die Möglichkeit diese als ein bestimmtes Mitglied aufzurufen nur Administratoren zur Verfügung steht.

[leofeyer]

Es ist korrekt, dass die Änderung aus #8425 das Verhalten insoweit geändert hat, als dass es jetzt auch beim Login und nicht mehr nur beim Logout auftritt. Beim Logout war es definitiv schon immer so.

Sicherheit und Benutzerfreundlichkeit sind konkurrierende Ziele und in diesem Fall war uns die Sicherheit eben wichtiger.

[Mynyx]

Dass man beim Logout sowohl im BE als auch im FE ausgeloggt wurde war auch schon zuvor so, das ist jedoch m. E. mit wesentlich geringeren Nachteilen verbunden. Denn nun ist es für normale Benutzer unmöglich gleichzeitig eingeloggt im Frontend und Backend zu arbeiten.

Gibt es denn keine Lösung, bei der sowohl Sicherheit als auch Benutzerfreundlichkeit gewahrt werden würden? Könnte man nicht, wenn der Benutzer bereits im BE oder FE eingeloggt ist, den diesbezüglichen in tl_session vorhandenen Eintrag aktualisieren und das entsprechende Cookie ebenfalls neu setzen?

[asaage]

@Mynyx die praktikabelste Lösung wie ich finde ist mit "inkognito-Fenster" (chrome) oder "privates Fenster" (firefox) zu arbeiten. Ich mach das jedenfalls schon ewig so.

[BugBuster1701]

so arbeite ich auch.

[leofeyer]

Eine weitere Möglichkeit ist die "angemeldet bleiben"-Option im FE. Dann kannst Du Dich beliebig im BE an- und abmelden und bleibst im FE trotzdem angemeldet.

[fritzmg]

@asaage @BugBuster1701 das ist nur ein Workaround, außerdem kannst du so keine versteckten/unpublished Elemente ansehen.

[aschempp]

Aus meiner Sicht ist das definitiv ein Bug und eine Veränderung des bisherigen Verhaltens.

[leofeyer]

Aus meiner Sicht ist das definitiv ein Bug

Nein.

und eine Veränderung des bisherigen Verhaltens.

Ja.

[aschempp]

Aus meiner Sicht ist das definitiv ein Bug

Nein.

Really? Stell dir mal die Arbeit damit vor.

1. du bist im Backend und richtest deinen Shop ein
2. du gehst ins Frontend und testest den Bestellprozess, loggst dich als Mitglied ein
3. du musst was umstellen, musst dich wieder im Backend anmelden
4. willst nochmals testen, musst dich wieder im Frontend anmelden
5. endless loop

[leofeyer]

Wie gesagt, es ist ein Trade-Off "Sicherheit gegen Benutzerfreundlichkeit". Wenn Du die FE-Vorschau verwendest, um das Mitglied anzumelden, hast Du das Problem nicht.

Ich hatte das neue Verhalten schon mit @discordier besprochen und wir waren beide der Meinung, dass die Änderung vertretbar ist hinsichtlich der erhöhten Sicherheit. Wir können es aber gerne nochmal diskutieren.

[aschempp]

Das hat doch nichts mit der Sicherheit zu tun? Wir müssen einfach beide Coolies neu setzten bei einer neuen Session ID ?

[leofeyer]

Können wir machen. Wir müssten dann nur in der User-Klasse irgendwie an die Cookie-Namen kommen, die momentan in den Unterklassen FrontendUser und BackendUser definiert werden.

[Toflar]

abstract protected function setUserCookie(); - analog zu setUserFromDb().

[leofeyer]

Das reicht nicht, denn bei der Anmeldung sind wir ja z.B. in der Klasse FrontendUser und brauchen trotzdem den Namen des Cookies aus der Klasse BackendUser. Wenn wäre es also public static function getCookieName().

[leofeyer]

Ist aber ein Design-Flow, wenn man in der Parent-Klasse feste Referenzen auf eine Child-Klasse hat. Zudem würde das nicht für weitere Child-Klassen von dritten Entwicklern funktionieren.

[asaage]

Ich glaube es war auch schon hin und wieder Gesprächsthema. Aber wie sieht es denn perspektivisch aus Mitglieder und Benutzer zu vereinen?
Meiner Meinung nach könnte das doch reichlich Vorteile Bringen bzgl. Frontend-editing, Rechtemanagement und nicht zuletzt auch in dieser Problematik.

[Mynyx]

In tl_session ist doch auch die Spalte name in welcher der Name des Cookies angegeben ist.

[Ainschy]

@leofeyer du vergisst bei deiner Argumentation das BE User ohne Adminrechte in der Frontend Vorschau keinen FE Member auswählen können und auch den direkt Login über den Mitgliederbereich im BE nicht haben.

Damit haben Redakteure keine Change auf gewohntem Wege sich im FE anzumelden und im BE zu bleiben.

[Paddy0174]

@leofeyer
Sorry, aber ich finde Deine Argumentation nicht ganz richtig. Der "normale" Weg sollte doch sein, dass es einen unterschiedlichen Login für FE und BE gibt, die beide erstmal gar nichts miteinander zu tun haben. Ich kann ja FE-Nutzer AB sein, und im BE bin ich Nutzer BA. Beides müsste doch voneinander unabhängig sein, wenn man schon Benutzer und Mitglieder trennt...?
Und dabei geht es ja nicht um Benutzerfreundlichkeit, sondern um Trennung von eben beiden Gruppen.
Insofern sollten die Logins doch völlig getrennt gehandhabt werden, oder verstehe ich das falsch?
Ich habe nämlich gerade das Problem, dass ich aus dem BE heraus einen Link auf eine FE-Seite aufrufen will, auf der ein Modul eingebunden ist, dass nur für angemeldete FE-Nutzer sichtbar ist... Wie sollte ich denn in so einem Fall vorgehen? Genauere Erklärung kann ich gerne nachliefern, wenn gewünscht?

[fritzmg]

Insofern sollten die Logins doch völlig getrennt gehandhabt werden, oder verstehe ich das falsch?

Du hättest dann zwei verschiedene Logins für die selbe Session.

[Paddy0174]

Ich meint auch eher, dass eben genau das nicht so ist. FE = Session1, BE = Session2...
Oder ich verstehe die Idee dahinter einfach nicht richtig => zwei Logins = zwei Sessions?!

[Mynyx]

Die Lösung für das Problem ist doch oben schon aufgezeigt, also was spricht eigentlich noch dagegen dass diese umgesetzt wird?

[frontendschlampe]

Gibt es hier noch irgendwie "Aktivität" oder wird das so bleiben, wie es jetzt ist?

[frontendschlampe]

Noch ein Hinweis dazu aus meinem Ticket #8705 - wenn man sich mit zwei verschiedenen Domains im FE und BE einloggt, dann funktioniert es.

[Paddy0174]

Es wäre schön, wenn sich jemand (wie Du z.B. @frontendschlampe ) darum kümmern würde. Im Zweifel auch gerne in einer Erweiterung... ;-)

So wie es jetzt ist, sollte es jedenfalls nicht bleiben. Sicherheit kann, wie ich finde, keine Begründung sein. Dann muss man eben einen Weg finden, der die gewünschte Funktionalität bei gleicher Sicherheit bietet.

[leofeyer]

@contao/developers Soll ich die Änderungen aus 9ae1234 rückgängig machen?

[Mynyx]

Was spricht denn dagegen das Cookie neu zu setzen? Der Name des Cookies steht ja wie bereits erwähnt in der Datenbank, sodass keine größeren Modifikationen an der User-Klasse notwendig sein dürften.

[aschempp]

Die bessere Lösung wäre es sicher das Cookie neu zu setzen. Ist aber halt umständlich… Mit Symfony Security sollte sich das erledigen, aber da das wohl noch etwas dauert und in 3.5 nicht kommt… von mir aus können wir die Änderung auch entfernen.

[leofeyer]

Wie am 18. Mai in Mumble besprochen, wollen wir in Contao 4.4 ein neues Feld "erlaubte Mitgliedergruppen" in den Benutzer(gruppen)-Einstellungen hinzufügen, damit Nicht-Admins sich in der Frontend-Vorschau als bestimmte Benutzer anmelden können.

[leofeyer]

Implementiert in contao/core-bundle@226a2c5.