Dies tritt weiterhin zufällig bei allen Benutzern auf. Mir ist es noch nicht passiert, aber ich wurde einmal abgemeldet, als es jemand anderem passierte. Ich habe keine Ahnung, wo ich überhaupt anfangen soll zu suchen.
Ich habe einen Thread in meinem Forum gestartet, den ich öffentlich gemacht habe, um weitere Informationen bereitzustellen. Diesmal wurden 2 Benutzer als derselbe Benutzer angemeldet, einer ein Administrator, der andere nicht. Der Benutzer, als der sie angemeldet wurden, ist nicht einmal aktiv.
@Falco Jede Einsicht, wo ich suchen soll, wird geschätzt.
@Falco, dies ist seit mehreren Jahren ein anhaltendes Problem. Soweit ich weiß, handelt es sich um ein Problem mit der clientseitigen Benutzersitzung und speziell mit der Benutzer-ID. Dieses Problem wird nur umgangen, aber nicht behoben, wenn anstelle der lokalen Anmeldung, d. h. der lokalen Authentifizierung, die Drittanbieter-Authentifizierung verwendet wird.
Können Sie bestätigen, dass dies auf Ihre unterdurchschnittliche lokale Authentifizierung zurückzuführen ist?
Mit allem Respekt, es gibt Tausende von Discourse-Installationen im Internet. Allein in unserem Hosting betreiben wir Tausende, und es gibt auch viele Self-Hosting-Installationen, und Ihre Instanz ist die einzige, die dieses Problem meldet. Das bedeutet, dass Ihr Problem höchstwahrscheinlich selbstverschuldet ist.
Da Sie einen benutzerdefinierten Reverse-Proxy vor Discourse betreiben, würde ich damit beginnen, diesen zu entfernen und zu unserem gesegneten Standard-Installationssetup zu wechseln, bevor Sie den Fehler hier melden.
Ich bin nicht sicher, was meinen benutzerdefinierten Aufbau im Vergleich zu dem, was in Discourse integriert ist, ausmacht, da beide nginx verwenden. Es ist für mich nicht möglich, es zu entfernen, da Discourse nicht die einzige Sache ist, die ich hoste. Ich bin mir sicher, dass es mein Problem ist, aber wenn es bei mir passieren kann, kann es auch bei jedem anderen passieren. Ich habe keine weiteren Probleme mit irgendeiner Software, die ich hoste. Ich bitte dich nicht, mir bei jedem Schritt die Hand zu halten, aber ich finde sonst nichts, was falsch sein könnte.
Wenn es keinen weiteren Hinweis gibt, den du geben könntest, wo man nachsehen sollte, kennst du vielleicht jemanden, der helfen kann. Ich habe versucht, die Logs beider Container sowie deren jeweilige Hosts zu überprüfen. Ich bin mir nicht sicher, wo ich noch nach dem Fehler suchen soll.
Ich kann das Fehlen von Unterstützung verstehen. Wir sind keine zahlenden Kunden und einige von uns sind nicht einmal sehr freundlich. Ich gebe dir nicht die Schuld, wenn du mit dem Finger auf mich zeigst, denn ich stimme zu, es ist etwas, das ich anders mache, das diesen Kopfschmerz verursacht. Wenn du jedoch wirklich glaubst, dass der Reverse Proxy das Problem verursacht, wäre das nicht eine riesige Sicherheitslücke?
Ich weiß nicht, was ich über die internen Abläufe von Discourse weiß, aber für mich scheint das etwas zu sein, das die Entwickler interessieren sollte.
Ja, das ist definitiv ein Sicherheitsproblem. Aber wenn es nur bei dieser spezifischen Instanz auftritt, ist es ein Sicherheitsproblem auf deiner Website und nicht bei Discourse, richtig?
Ich helfe gerne weiter. Wärst du bereit, die Website für ein paar Wochen auf einen separaten Server zu verschieben und unsere Standardinstallation zu verwenden, um Probleme mit dem Reverse-Proxy auszuschließen?
Wenn mein Reverse-Proxy ein Token oder etwas anderes auf die richtige Weise verfälschen kann, sodass Discourse glaubt, ein Benutzer sei jemand anderes geworden … spielt es dann wirklich eine Rolle, ob das Problem beim Reverse-Proxy liegt? Würde dies nicht auf etwas hindeuten, das anderswo ausgenutzt werden kann?
Wiederum, ohne zu wissen, was ich nicht weiß, wie die Authentifizierung funktioniert.
Wir sind aufgrund gestiegener Kosten vom Hosting durch Dritte weggegangen, aber es gibt vielleicht einen anderen Weg, dies anzugehen. Ich werde den Reverse-Proxy untersuchen. Derzeit verwende ich diesen Container zur einfachen Verwaltung, könnte aber etwas anderes versuchen.
Ich weiß, Sie sagen, dass es nur bei mir passiert, und ich habe keine Beweise für das Gegenteil, aber bedeutet das wirklich, dass es für niemanden sonst möglich ist?
Ich werde die Nginx-Konfiguration, die Discourse mitliefert, genauer untersuchen, um zu verstehen, wo ich etwas falsch mache. Ich schätze Ihre Einsichten.
Ich behaupte nicht, dass ich hier und jetzt etwas verstehen würde, aber als ich anfing, Discourse zu benutzen, hatte ich Varnish vor Discourse und erlebte viele seltsame Dinge, wie falsche Inhalte.
Discourse macht sein eigenes Caching und praktisch jede Art von Caching durch einen Reverse-Proxy ist eine sehr schlechte Idee. Aber sicher, meine sehr begrenzten Fähigkeiten sind etwas ganz anderes als das, was die Großen Jungs ™ tun können.
Er wollte, dass ich den Reverse-Proxy komplett entferne. Dies ist einfach das Entfernen einiger Dinge aus der Proxy-Konfiguration. Ich wusste nicht, dass Discourse intern Caching betreibt, das mit externem Caching in Konflikt geraten würde, daher ist das ein nützlicher Vorschlag.
[quote=“Jakke Lehtonen, post:33, topic:328698, username:Jagster”]
Du wirst also im Grunde das tun, was Falco schon mehrmals vorgeschlagen hat
[/quote]Der Link, den er ständig spammt, ist das, was wir bereits tun:
diese Schritte funktionieren auf jedem Docker-kompatiblen Cloud-Anbieter oder lokalen Server.
Er verwendet den Standardcontainer. Die Dokumentation erwähnt die Verwendung einer „Docker-kompatiblen“ Box, was er tut. Die Dokumentation erwähnt sogar die Verwendung eines lokalen Servers, was er tut.
Es gibt keine Erwähnung der Verwendung eines speziellen genehmigten Proxys oder der Deaktivierung des Cachings.
Es gibt auch eine Dokumentation zur Konfiguration von SSO, die in der Vergangenheit ähnliche Probleme verursacht zu haben scheint, wie wir sie gerade erleben:
Immer noch keine Erwähnung von Caching-Konfigurationen oder „benutzerdefinierten“ Reverse-Proxy-Lösungen.
Ich würde zumindest vorschlagen, die Dokumentation zu aktualisieren, um diese potenziellen Probleme hervorzuheben, da sie für Discourse-Experten so offensichtlich sind.
Ich wäre sehr nervös wegen dieser Caching-Konfiguration. Ich verstehe die Nginx-Dokumentation für proxy_ignore_headers nicht vollständig, aber standardmäßig cacht Nginx keine Antworten, die einen Set-Cookie-Header enthalten. Es sieht so aus, als ob diese Konfiguration dieses Verhalten ändert, sodass Antworten, die einen Set-Cookie-Header enthalten, möglicherweise gecacht werden. Wenn sie mit dem Set-Cookie-Header gecacht und dann einem anderen Benutzer serviert werden, könnte dies dazu führen, dass jemand sein Benutzerkonto wechselt.
Theoretisch sollte sich diese Konfiguration nur auf Mediendateien auswirken, aber das Abgleichen des Endes einer URL (einschließlich Abfrageparametern?) scheint eine ziemlich unsichere Methode dafür zu sein.
Ich habe seine Verwendung eingestellt. Da andere darauf hingewiesen haben, scheint es insgesamt eine ziemlich schlechte Idee zu sein. Ich schätze die Erklärung. Ich habe auf Anhieb nichts Falsches an dem, was es tat, gesehen, aber ich bin definitiv kein Experte auf diesem Gebiet.
