Support oder "Wann ist ein Contao-Fehler ein Fehler?"

[fmbcf]

Ich habe gerade ein sehr interessantes Erlebnis: Ich kann mich in meinem Backend nicht mehr anmelden und komme als Administrator somit nicht mehr an mein System (siehe https://community.contao.org/de/show...ert-nicht-mehr).

Da mich das System laut Log hineinläßt und dann sofort wieder auslogt, habe ich das Ganze als Bug im GitHub gepostet ([core] Backend-Login scheitert (#6047))
Der Bug wurde heute als Invalid von Leo Feyer geschlossen mit der Bemerkung, ich solle mich ans Forum wenden. Auf meine Frage, warum ich mich mit einem Programmierfehler ans Forum wenden solle, kam die Entgegnung:

Da es in der Onlinedemo funktioniert, liegt offensichtlich kein Programmierfehler vor.

Daraus folgt, ein Programmierfehler liegt nur dann vor, wenn er in der Onlinedemo nachvollziehbar ist. Cooler Ansatz!

Glen Langer postete dann noch:

Dieses Thema gibt es auch schon öfters im Forum, also nix wie hin und dort die Suche benutzen.
Das kann mehrere Gründe haben (falsche Server Zeit / Zeitzonen / Cookie Blocker / usw.)

Mal abgesehen davon, dass mir derlei Probleme bei anderen Systemen in der Form noch nicht begegnet sind (was für eine zumindestens wenig robuste Programmierung des Backend-Logins spricht), müßte man aus meiner Sicht mindestens das Folgeverhalten als fehlerhaft qualifizieren. Wenn dem System Serverzeiten, Cookiemängel oder ähnliches aufstossen, dann sollte es eine geeignete Fehlermeldung ausgeben statt zu schweigen.

Das Ganze mag Interessierten den Blick auf Contao abrunden.
Der Vorgang könnte vielleicht auch eine Diskussion in der Community auslösen:
Wann ist ein Bug ein Bug?
Wann ist ein Log ein Log?
Darf ein Login kommentarlos an Serverzeiten, Cookies o.ä. scheitern und weder das noch die Kommentarlosigkeit ist dann ein Bug ?

[BugBuster]

Wenn es sich bei den genannten Dingen um Sicherheitsfeatures handelt, dann ist das sehr wohl nachvollziehbar, dass es kein Bug in Contao ist.

Ich stimme dir zu, das es manchmal doch etwas hilfreich wäre den Grund für den sofortigen Logout zu erfahren. Das wird leider nicht klar in manchen Fällen.

Gründe wie gesagt gibt es mehrere die hier auch schon im Forum auftauchten.
Beispiel Session Zeit. Die Session ist nur für eine bestimmte Zeit gültig bei Inaktivität aus Sicherheitsgründen. Läuft diese ab wird diese gelöscht.
Stimmt nun was mit den Uhrzeiten nicht (durch Fehlkonfiguration am Server schon vorgekommen), ist die Session bei Login sofort ungültig und man wird abgemeldet.
Klingt erst mal unlogisch, ist es aber nicht, glaub mir.

Ebenso könnte ein Loadbalancer in der Strecke zwischen Dir und dem Server sein. Der führt dazu, das bei jedem Klick (wenn der doof konfiguriert ist) eine andere IP am Server ankommt, die Session wird nicht erkannt, Peng bist du draußen.

Einiges davon kann man in der localconfig.php deaktivieren um zu testen ob es daran liegt.

[fmbcf]

...Beispiel Session Zeit. Die Session ist nur für eine bestimmte Zeit gültig bei Inaktivität aus Sicherheitsgründen. Läuft diese ab wird diese gelöscht. Stimmt nun was mit den Uhrzeiten nicht (durch Fehlkonfiguration am Server schon vorgekommen), ist die Session bei Login sofort ungültig und man wird abgemeldet. Klingt erst mal unlogisch, ist es aber nicht, glaub mir.

Ebenso könnte ein Loadbalancer in der Strecke zwischen Dir und dem Server sein. Der führt dazu, das bei jedem Klick (wenn der doof konfiguriert ist) eine andere IP am Server ankommt, die Session wird nicht erkannt, Peng bist du draußen.

Einiges davon kann man in der localconfig.php deaktivieren um zu testen ob es daran liegt.

Zur Sessionzeit: das gehört dann ins Log "User xyz logged out wg. Sessiontimeout" ! Dagegen spricht, das es von bestimmten Infrastrukturen aus klappt, von anderen aus nicht. Am (Strato-)Server dürfte es demnach nicht unbedingt liegen

Zu dem IP-Nummerngedöns: Dito! "User xyz logged out wg. IP-Nummernwechsel" Dann hätte man ja zumindestens mal einen Anhaltspunkt.

localconfig.php: Wo ist die Referenzdoku für diese Konfig-Datei? Eine Suche über contao.org führte zu Null Treffern.

[lucina]

Das kommt ja auch immer ein wenig darauf an wie du das errorreporting konfigurierst - ggf. bekommt eine Webanwendung davon erstmal gar nichts mit und beendet trotzdem die Session aufgrund eines unpassenden Tokens.

Keine Ahnung, wie Du das bei Strato einstellen kannst (und ob überhaupt).

Die localconfig dient zum Überschreiben von Core-Werten. Da die ab Werk gar nicht vorhanden ist kann es da auch keine Doku geben. Grundsätzlich kannst Du alles, was im Core (in der config.php) und woanders (in Modulen) an Werten steht in der localconfig überschreiben. Das ist schon die ganze Magie.

[ciaobello]

Daraus folgt, ein Programmierfehler liegt nur dann vor, wenn er in der Onlinedemo nachvollziehbar ist. Cooler Ansatz!

Wie würdest Du es denn machen? Irgend einen gemeinsamen Nenner braucht es doch um Ungereimtheiten festzustellen?

Wenn dem System Serverzeiten, Cookiemängel oder ähnliches aufstossen, dann sollte es eine geeignete Fehlermeldung ausgeben statt zu schweigen.

Wo in aller Welt soll Contao die Fehlermeldungen her nehmen? Wenn während den Betatests auf github nicht genügend feedback zurück kommt, von Personen welche es auf verschiedenen Systemen installieren/testen, werden die von Dir gewünschten Meldungen auch nicht erfasst werden und auch nicht dementsprechend angezeigt.

[jr1337]

Kannst dich ja hinsetzen und 10 Minuten durchdebuggen - dann siehst du ja wo er "rausspringt"

[jan.theofel]

Hi,

Wo in aller Welt soll Contao die Fehlermeldungen her nehmen? Wenn während den Betatests auf github nicht genügend feedback zurück kommt, von Personen welche es auf verschiedenen Systemen installieren/testen, werden die von Dir gewünschten Meldungen auch nicht erfasst werden und auch nicht dementsprechend angezeigt.

Das sehe ich anders. Zumindest IRGENDEINE Meldung sollte Contao ausspucken. Und so Vorgänge wie Invalid Session/Invalid Ip/... kennt Leo auch unabhängig von Betatests.

Gleiches gilt für das Update-Tool auf Contao 3: Hier werden diverse SQL-Operationen einfach ohne jede Fehlerprüfung durchgeführt. Das führte bei mir u.a. dazu, dass alle Inhalte der News gelöscht wurden. Da kannst du auch sagen: Hat halt kein Beta-Tester bemerkt. Ja, aber das ist noch lange keine Entschuldigung für einen schlechten Code. Ein vernünftiges Fehlerhandling gehört in jeden Code!

Jan

[fmbcf]

Kannst dich ja hinsetzen und 10 Minuten durchdebuggen - dann siehst du ja wo er "rausspringt"

Nein, kann ich nicht, da ich kein PHP beherrsche und mir nicht klar war, dass ich das können muss, um Conato störungsfrei zum Laufen zu bringen. Außerdem müßte ich das PHP bei Strato debuggen, weil das Problem dort auftritt und nicht in meinem lokalen XAMPP. Da weiß ich noch weniger, ob ich dort überhaupt debuggen darf und wenn ja, wie das geht. Deshalb wären ja aussagekräftige Fehlermeldungen in irgendeinem Log sehr hilfreich.

[fmbcf]

Wie würdest Du es denn machen? Irgend einen gemeinsamen Nenner braucht es doch um Ungereimtheiten festzustellen?
Wo in aller Welt soll Contao die Fehlermeldungen her nehmen? Wenn während den Betatests auf github nicht genügend feedback zurück kommt, von Personen welche es auf verschiedenen Systemen installieren/testen, werden die von Dir gewünschten Meldungen auch nicht erfasst werden und auch nicht dementsprechend angezeigt.

Ich habe kein Problem damit, dass im Backend-Login ein Bug schlummert. Ich habe auch kein Problem damit, dass der in der Betaphase nicht entdeckt wird, weil es dazu womöglich wenig verbreiteter Kombinationen zwischen Strato-Betriebsumgebung und Nutzer sitzt hinter Proxy im Firmennetz bedarf und die Contao-Gemeinde zu klein für alle möglichen Testszenarien ist. Wenn dann allerdings nach Release-Rollout ein solcher Bug entdeckt wird, finde ich es insbesondere für weitere Contao-Interessenten hilfreich zu wissen, dass ein Bug bei Contao kein Bug, sondern nur eine Ungereimtheit ist, wenn er nicht in einer wie auch immer strukturierten onlineDemo reproduzierbar ist.

Meine Bereitschaft, Feedback in das GitHub einzuspeisen, ist durch diesen Umgang mit der Meldung nicht gerade beflügelt worden.

[lucina]

Ich habe kein Problem damit, dass im Backend-Login ein Bug schlummert. Ich habe auch kein Problem damit, dass der in der Betaphase nicht entdeckt wird, weil es dazu womöglich wenig verbreiteter Kombinationen zwischen Strato-Betriebsumgebung und Nutzer sitzt hinter Proxy im Firmennetz bedarf und die Contao-Gemeinde zu klein für alle möglichen Testszenarien ist. Wenn dann allerdings nach Release-Rollout ein solcher Bug entdeckt wird, finde ich es insbesondere für weitere Contao-Interessenten hilfreich zu wissen, dass ein Bug bei Contao kein Bug, sondern nur eine Ungereimtheit ist, wenn er nicht in einer wie auch immer strukturierten onlineDemo reproduzierbar ist.

Meine Bereitschaft, Feedback in das GitHub einzuspeisen, ist durch diesen Umgang mit der Meldung nicht gerade beflügelt worden.

Ohne Dich jetzt abmeiern zu wollen: ist es nicht so, dass User für ihren Setup selbst verantwortlich sind? Und ist es nicht weiterhin so, dass einem User bewusst sein sollte, was passiert (und überall passieren kann) wenn man hinter mehreren Proxies sitzt und wechselnde IP-Adressen hat? Und ist es nicht weiterhin so, dass man als User dann auch damit klarkommen muss und entweder seinen Setup anpasst oder auf dem Zielsystem Maßnahmen trifft damit das keine Folgen hat? Und das Contao für diesen Fall einen Mechanismus bietet?

Im Übrigen ist das ja kein Strato-Problem, genauso, wie es kein Contao-Problem ist. Ich kann mich noch sehr gut an den 'Internetprovider mit den vielen CDs' erinnern, der ganz routiniert allen Traffic über Loadbalancer schubste und damit IP-basierte Sessions gründlichst konterkarierte. Dagegen gab es verschiedene wohlbekannte Mittel, die alle darauf hinausliefen, das Sessionmanagement zu hacken (und in Folge wesentlich weniger Sicherheit für Webapplikationen bedeuteten). Ich kann mich genauso dran erinnern, dass ich aus bestimmten Onlineshops rausfliege, wenn meine Proxies nicht korrekt konfiguriert sind (die kann man nämlich auch so einstellen dass sie transparent durchreichen ...).

Schließlich: die Antwort im Bugtracker fand ich inhaltlich richtig. Hier im Forum gibt es etliche Beiträge, die sich mit dem Thema beschäftigen, und es gibt Lösungsszenarien. Ein Bug wäre aus meiner Sicht, wenn diese Lösungsszenarien aufgrund einer Fehlfunktion nicht zum Ziel führten weil die Funktion fehlerhaft implementiert ist. Ein Bug wäre es aus meiner Sicht nicht, wenn ein Verhalten von Contao genau so beabsichtigt ist. Ein Feature Request wäre es, wenn man die Funktionalität nicht für ausreichend hält (und dann optimalerweise Lösungsvorschläge dazu macht).

Just my 2 cents.

[fmbcf]

Ohne Dich jetzt abmeiern zu wollen: ist es nicht so, dass User für ihren Setup selbst verantwortlich sind? Und ist es nicht weiterhin so, dass einem User bewusst sein sollte, was passiert (und überall passieren kann) wenn man hinter mehreren Proxies sitzt und wechselnde IP-Adressen hat? Und ist es nicht weiterhin so, dass man als User dann auch damit klarkommen muss und entweder seinen Setup anpasst oder auf dem Zielsystem Maßnahmen trifft damit das keine Folgen hat? Und das Contao für diesen Fall einen Mechanismus bietet?

Ich habe mich (gerade als Neuling!) an die Installationsanleitung gehalten und das System geradeaus ohne Tricks installiert. Was die Proxy-Thematik angeht: Ich sitze in einem Firmennetz und habe noch nie Probleme wie die beschriebenen erlitten. Das spricht eher gegen die These, unsere Firmenproxies seien "schuld". Ich würde ja gerne auf dem Zielsystem Maßnahmen ergreifen, aber solange ich noch nicht mal einen detaillierten Logeintrag bekomme, ist das schwierig. Und spätestens das ist aus meiner Sicht ein Bug. Welchen Mechanismus meinst Du?

Schließlich: die Antwort im Bugtracker fand ich inhaltlich richtig. Hier im Forum gibt es etliche Beiträge, die sich mit dem Thema beschäftigen, und es gibt Lösungsszenarien. Ein Bug wäre aus meiner Sicht, wenn diese Lösungsszenarien aufgrund einer Fehlfunktion nicht zum Ziel führten weil die Funktion fehlerhaft implementiert ist. Ein Bug wäre es aus meiner Sicht nicht, wenn ein Verhalten von Contao genau so beabsichtigt ist. Ein Feature Request wäre es, wenn man die Funktionalität nicht für ausreichend hält (und dann optimalerweise Lösungsvorschläge dazu macht).

Den User ins Backend reinzulassen, um ihn dann kommentarlos im gleichen Request wieder rauszuwerfen ist imho ein Bug! Wenn die Funktion "Backend-Login" fehlerfrei programmiert wäre, würde sie den User entweder gar nicht reinlassen oder ihn nicht im gleichen Request ohne jeglichen Kommentar wieder rauswerfen. Solch ein Systemverhalten würde bei uns auf jeden Fall Eingang in die Bugliste finden und wäre je nach Verbreitung sogar abnahmeverhindernd. Wohlgemerkt, direkt-wieder-rauswerfen ist das eine, kommentarlos ist das andere.

PS: Ich habe durchaus im Forum gesucht, aber etliche Beiträge habe ich nicht gefunden, sondern vor allem https://community.contao.org/de/show...ert-nicht-mehr, bei dem aber alle Punkte nicht zutrafen.

[ciaobello]

PS: Ich habe durchaus im Forum gesucht, aber etliche Beiträge habe ich nicht gefunden, sondern vor allemhttps://community.contao.org/de/show...ert-nicht-mehr, bei dem aber alle Punkte nicht zutrafen.

Vielleicht solltest Du nach dem Prinzip der Ursachen-Bekämpfung suchen und nicht danach was aus Deinem Problem resultiert. Wenn Du nach Login Problem Suchst aber ein Proxy dazwischen liegt, ist Dein Ansatz des Problem Debuggen falsch und Du kannst hier noch lange Rechtfertigungen suchen und Reklamieren.

Contao Google-Suche >> contao proxy

Hoffe dass Du uns im nachhinein noch ein Feedback gibst was das wirkliche Problem war.

[fmbcf]

Vielleicht solltest Du nach dem Prinzip der Ursachen-Bekämpfung suchen und nicht danach was aus Deinem Problem resultiert. Wenn Du nach Login Problem Suchst aber ein Proxy dazwischen liegt, ist Dein Ansatz des Problem Debuggen falsch und Du kannst hier noch lange Rechtfertigungen suchen und Reklamieren.
Contao Google-Suche >> contao proxy
Hoffe dass Du uns im nachhinein noch ein Feedback gibst was das wirkliche Problem war.

(A) Dass es am Proxy liegt, mag für Dich offensichtlich sein. Für Leute, die nicht auf Deinem Niveau und mit Deiner Erfahrung operieren wäre es hingegen nützlich, auf diesen Umstand im Logfile hingewiesen zu werden ("User Müller logged out due to conflicting IP"). Dann kann ich auch die vielleicht richtigen Suchbegriffe eingeben und stosse dann auf Seite 2 der Trefferliste auf einen nützlichen Hinweis. Insofern bleibe ich dabei, dass der kommentarlose Logout noch im laufenden Loginrequest imho ein Bug ist.

(B) Dieser Thread diente dazu, das Fehlerklassifizierungsvorgehen auf Contao.org zu erörtern. Die Lösung des Problems habe ich an die Stelle geschrieben, bei der ich bei der meiner Suche gestrandet bin: https://community.contao.org/de/show...ert-nicht-mehr.
(Suchbegriffe: Login zum Backend funktioniert nicht mehr)

[ciaobello]

(A) Dass es am Proxy liegt, mag für Dich offensichtlich sein. Für Leute, die nicht auf Deinem Niveau und mit Deiner Erfahrung operieren wäre es hingegen nützlich, auf diesen Umstand im Logfile hingewiesen zu werden ("User Müller logged out due to conflicting IP"). Dann kann ich auch die vielleicht richtigen Suchbegriffe eingeben und stosse dann auf Seite 2 der Trefferliste auf einen nützlichen Hinweis. Insofern bleibe ich dabei, dass der kommentarlose Logout noch im laufenden Loginrequest imho ein Bug ist.

(B) Dieser Thread diente dazu, das Fehlerklassifizierungsvorgehen auf Contao.org zu erörtern. Die Lösung des Problems habe ich an die Stelle geschrieben, bei der ich bei der meiner Suche gestrandet bin: https://community.contao.org/de/show...ert-nicht-mehr.
(Suchbegriffe: Login zum Backend funktioniert nicht mehr)

A) Es wurde mir ersichtlich Durch aufmerksames durchlesen des Thema hier ... ich wollte Dir nur helfen Dein Problem zu lösen indem ich vorgeschlagen habe mit anderen Suchbegriffen zu suchen welche die Ursache beheben und nicht die Folge bekämpfen.
Schliese Dich mit Deiner Informatik Abteilung kurz und lass Dir zeigen wie Du mit Contao hinter einem Proxy arbeiten kannst. Die sollten hoffentlich wissen wie und warum Sie einen Proxy eingerichtet haben und wie man über den erfolgreich ins Internet kommt.

B) Ob das hier ein "konstruktives erörtern" wird oder wieder nur ein "Sich auskotzen Thema" wird sich zeigen. Github ist eigentlich die Platform wo konstruktive Vorschläge zur Verbeserung von Contao ausgearbeitet werden. Und auch dort sollte nicht im Tonfall "Hey ... contao ist Scheisse ... macht mal besser" komuniziert werden!

Leider ist das Zur Zeit generell wieder Mode hier im Forum ... Sich herablassend über andere zu äußern und Schuldzuweisungen vorzunehmen. Aber es besteht nicht wirklich das Interesse Contao zu verbessern mit konstruktiven Vorschlägen! Weder hier im Forum noch auf Github.

[BugBuster]

Den User ins Backend reinzulassen, um ihn dann kommentarlos im gleichen Request wieder rauszuwerfen ist imho ein Bug!

Ich sehe das als fehlendes Feature, was die Meldung des Grundes betrifft.
Wie Leo ja auch schrieb, ist das aus Contao Sicht kein Bug wenn der Zugriff so nicht klappt.

Daher, mach ein Feature Request mit der Bitte zum besseren Verständnis der erfolglosen Logins den entsprechenden Grund auszugeben.

[lucina]

Wobei ich mich frage was da protokolliert werden soll - wenn der User eingeloggt ist, okay. Aber rausgeflogen: das geht ja gerade nicht mit Hinterlegung des Users, weil der ja nicht mehr da ist ...

BTW, Mechanismus: Einstellungen -> IP-Prüfung deaktivieren

[fmbcf]

A) Es wurde mir ersichtlich Durch aufmerksames durchlesen des Thema hier ... ich wollte Dir nur helfen Dein Problem zu lösen indem ich vorgeschlagen habe mit anderen Suchbegriffen zu suchen welche die Ursache beheben und nicht die Folge bekämpfen.
Schliese Dich mit Deiner Informatik Abteilung kurz und lass Dir zeigen wie Du mit Contao hinter einem Proxy arbeiten kannst. Die sollten hoffentlich wissen wie und warum Sie einen Proxy eingerichtet haben und wie man über den erfolgreich ins Internet kommt.
B) Ob das hier ein "konstruktives erörtern" wird oder wieder nur ein "Sich auskotzen Thema" wird sich zeigen. Github ist eigentlich die Platform wo konstruktive Vorschläge zur Verbeserung von Contao ausgearbeitet werden. Und auch dort sollte nicht im Tonfall "Hey ... contao ist Scheisse ... macht mal besser" komuniziert werden!
Leider ist das Zur Zeit generell wieder Mode hier im Forum ... Sich herablassend über andere zu äußern und Schuldzuweisungen vorzunehmen. Aber es besteht nicht wirklich das Interesse Contao zu verbessern mit konstruktiven Vorschlägen! Weder hier im Forum noch auf Github.

Wenn Du dann an Deinem Boxsack fertig bist und Deinen schnauzigen Ton deutlich runterpegelst, sag Bescheid.

[fmbcf]

Ich sehe das als fehlendes Feature, was die Meldung des Grundes betrifft.
Wie Leo ja auch schrieb, ist das aus Contao Sicht kein Bug wenn der Zugriff so nicht klappt.
Daher, mach ein Feature Request mit der Bitte zum besseren Verständnis der erfolglosen Logins den entsprechenden Grund auszugeben.

Danke für den Hinweis. Gerade als Newbie habe ich natürlich inzwischen mehrere FeatureRequests im Kopf, insbesondere auch zum Handling. Ich habe gerade per Google-Suche auf den ersten beiden Trefferseiten keine Erläuterung gefunden, wie man einen solchen FR erzeugt. Im Github finde ich zwar die Möglichkeit "Issues" einzugeben, aber wie erzeuge ich dort einen FR. Gibt's dazu hier irgendwo eine Anleitung?

[fmbcf]

Wobei ich mich frage was da protokolliert werden soll - wenn der User eingeloggt ist, okay. Aber rausgeflogen: das geht ja gerade nicht mit Hinterlegung des Users, weil der ja nicht mehr da ist ...
BTW, Mechanismus: Einstellungen -> IP-Prüfung deaktivieren

Da das System in der Lage ist, den Benutzer rauszuwerfen und das zu protokollieren ("User xyz logged out"), sollte es auch möglich sein, die Ursache mitzuprotokollieren. Ohne jetzt in eine Germanismusdebatte abgleiten zu wollen, könnte man ja hergehen und "User logged out" für das aktive Ausloggen des Users per "Abmelde"-Button reservieren. Wenn aber das System von sich aus den User rauskickt, weil die Session abgelaufen ist oder die IP-Adresse sich geändert oder was weiß ich, dann könnte man "Session terminated for User xyz due to ..." verwenden.

[BugBuster]

Im Github finde ich zwar die Möglichkeit "Issues" einzugeben, aber wie erzeuge ich dort einen FR. Gibt's dazu hier irgendwo eine Anleitung?

Geh einfach mal davon aus, dass ein Issue nicht nur ein Bug sein darf.

Einfach rein damit. Wenn der Betreff schon als Feature erkannt wird wäre das gut, notfalls "Feature:" voranschreiben, machen manche habe ich gerade gesehen.

[fabil]

Geh einfach mal davon aus, dass ein Issue nicht nur ein Bug sein darf.

Einfach rein damit. Wenn der Betreff schon als Feature erkannt wird wäre das gut, notfalls "Feature:" voranschreiben, machen manche habe ich gerade gesehen.

Leider finde ich es oft sehr schade, dass auch kleine Verbesserungen einfach abgelehnt werden.
z.B. wollte ich darauf hinweisen, dass die Beschreibung 'Letzte Anmeldung' bei Benutzer&Mitglieder im BE nicht stimmt, da dort immer die vorletzte Anmeldung ausgegeben wird. Entweder man nimmt dort den currentLogin-Timestamp oder benennt dies um. Aber wurde natürlich einfach geschlossen.

Das ist doch kein Problem sowas zu ändern, und weniger Leute wundern sich dann, wieso der Zeitstempel von Letzter Anmeldung nicht mit der tatsächlichen letzten Anmeldung übereinstimmt.

[BugBuster]

Was die letzte Anmeldung betrifft habe ich hier schon hunderte Male erklärt.

Der Text "Letzte Anmeldung vor der aktuellen sofern online" passt da nun mal nicht hin.
Das DB Feld ich richtig, auch die Bedeutung, da diese ursprünglich für die Frontend Anzeige entwickelt wurde und bis heute verwendet wird.

[fabil]

Was die letzte Anmeldung betrifft habe ich hier schon hunderte Male erklärt.

Der Text "Letzte Anmeldung vor der aktuellen sofern online" passt da nun mal nicht hin.
Das DB Feld ich richtig, auch die Bedeutung, da diese ursprünglich für die Frontend Anzeige entwickelt wurde und bis heute verwendet wird.

Klar, da Stimme ich dir zu. Aber wieso sortiert man nicht einfach mithilfe von currentLogin im BE und gibt die Info im FE anhand von lastLogin aus? Denn im BE passt eben die Bedeutung nicht wirklich, da sie - wie du selbst sagst - ursprünglich aus dem Frontend kommt. Durch die Änderungen entstehen meiner Meinung nach keine Nachteile, oder siehst du dort welche? ;-)

[BugBuster]

Weil im FE ja nicht angezeigt werden soll, sie sind grad online, sondern wann er/sie zuletzt online war.
Außerdem stimmt sogar die Anzeige im BE bei Nutzern die nicht gerade online sind.
"Vorletzte Anmeldung" passt ja auch nicht bei offline Nutzern in der BE Anzeige.

[Spooky]

Wobei ich mich frage was da protokolliert werden soll - wenn der User eingeloggt ist, okay. Aber rausgeflogen: das geht ja gerade nicht mit Hinterlegung des Users, weil der ja nicht mehr da ist ...

BTW, Mechanismus: Einstellungen -> IP-Prüfung deaktivieren

Warum sollte das nicht gehen, vorausgesetzt der User wird durch Contao ausgelogged? Das sollte wohl doch keine Problematik darstellen einen Log Eintrag zu machen, wenn festgestellt wird, dass der User ausgelogged werden muss (bevor er tatsächlich ausgelogged wird).

[lucina]

Ich denke, der wird nicht von Contao ausgeloggt sondern es gibt in dem Moment schlicht keine gültige Session - wäre also vermutlich eher ein Access denied, oder sehe ich das jetzt komplett falsch?

[fiedsch]

Ich denke eher, nein. Er kommt mit einer Session-ID die als nicht mehr gültig erachtet wird, weil sich die IP geändert hat. Das geschieht durch Contao und in sofern weiß es Bescheid.

[BugBuster]

Ich denke, der wird nicht von Contao ausgeloggt sondern es gibt in dem Moment schlicht keine gültige Session - wäre also vermutlich eher ein Access denied, oder sehe ich das jetzt komplett falsch?

Sagen wir mal so, eine der Ursachen könnte sein, dass genau die Session verloren geht und Contao ihn daher gleich wieder ausloggt. So ist es ja im Log zu sehen.
Ich war vor langer Zeit mal in der Methode und habe mir das damals auch angesehen, weil ich auch mal das Problem hatte. Ist aber lange her.

[fiedsch]

Was ich meinte, war: wenn im Log steht "User XYZ logged off", dann kann die Session nicht verloren gegangen sein, da Contao ja noch weiß, daß es User XYZ war. In diesem Fall könnte/sollte dann auch ein Grund angegeben werden.

[BugBuster]

Da ich grad im Quelltext schaue, von welcher Contao Version reden wir hier, 2.11 oder 3.1?

[BugBuster]

Ich habe mal geschaut, in 2.11 und in 3.1.
Es gibt in der User->authenticate() nur ein "Rauswurf" der ohne Meldung ist, alle anderen haben mittlerweile eine Meldung.
Und die ist genau dann der Fall, wenn der Hash gebildet aus session-id + cookie + IP nicht identisch mit dem vorherigem Aufruf ist.

Hier könnte es nun mehrere Möglichkeiten geben, je nach dem ob der Zugriff von anderen Clients (nicht über proxy | loadbalancer | sonst für'n Dreck) funktioniert oder nicht.
- Server Fehler, kann keine Session Dateien anlegen (tmp Fehler z.B)
- irgendwas blockiert cookies
- IP Wechsel zw. den Seiten Aufrufen (Gründe hier schon genannt)
- sicher noch weiteres...

Zum Test kann ja mal jemand der dieses Problem hat diese Zeile ändern (C3.1.1)
https://github.com/contao/core/blob/.../User.php#L168

return false; 

zu:

$this->log('Cookie hash checking was false.', get_class($this) . ' authenticate()', TL_ACCESS);
return false; 

Kommt nun obige Meldung, haben wir die Stelle gefunden die es Wert wäre hier eine Meldung zu bringen.

Oder noch einfacher, in der localconfig.php den IP Check abschalten:

$GLOBALS['TL_CONFIG']['disableIpCheck'] = true; 

Geht dann der Login, haben wir dieselbe Stelle und somit auch den Grund gefunden.

[BugBuster]

Nachtrag: Die Meldung kommt im BE System-Log, nicht auf der Webseite.
Wer da nun nicht rein kommt, schaut in die Tabelle tl_log die letzten Einträge an.