Beibehaltung von Benutzersitzungen bei der Migration zwischen Hosts

Unterstützung Installation
1

Hallo!

Ich bereite gerade die Migration einiger Discourse-Instanzen auf einen neuen Host vor. Der Plan ist, die alte Seite schreibgeschützt zu setzen, ein Backup zu erstellen, dieses auf den neuen Host zu übertragen und wiederherzustellen, während gleichzeitig die DNS-Einstellungen aktualisiert werden (mit einer kurzen TTL). Dieser Prozess basiert auf Anleitungen hier und anderswo.

Ich habe bereits einige Testläufe durchgeführt, indem ich einen Hack über die Datei /etc/hosts verwendet habe, um die DNS-Aktualisierung zu simulieren (und DNS over HTTPS war im Browser ebenfalls deaktiviert). Bisher läuft alles gut.

Trotzdem vergisst der Browser die Anmeldung, obwohl ich sorgfältig darauf geachtet habe, den Browser auf der „Quellseite

2

Ich hatte dieses Problem auch und bin sehr daran interessiert, es zu lösen.

Jegliche Hinweise wären willkommen.

3

Ich denke, ich werde versuchen, einige Testkonten ohne 2FA zu erstellen, falls das damit zusammenhängt – nur sehr wenige Mitglieder der Seite nutzen 2FA, sodass das vielleicht akzeptabel ist, wenn nur diese Sitzungen verloren gehen.

Außerdem werde ich prüfen, ob Quell- und Zielserver mit NTP synchronisiert sind, obwohl sie meiner Meinung nach jetzt nicht mehr als ein paar Sekunden voneinander abweichen können.

Abgesehen davon gibt es natürlich immer noch den Quellcode, um herauszufinden, was in das Authentifizierungstoken eingeht und möglicherweise Probleme verursacht … :grimacing:

4

Am besten informieren Sie Ihre Benutzer über die Änderung, dass sie abgemeldet werden und sich erneut anmelden müssen.

Jeder Server hat mit aktiviertem SSL eine eindeutige Signatur.

Es ist weniger aufwendig, die Benutzer erneut anmelden zu lassen, als Servereinstellungen zu ändern.

Entschuldigen Sie sich einfach für die entstandenen Unannehmlichkeiten, aber weisen Sie darauf hin, dass dies zum Wohle aller geschieht.

5

Ist das wirklich so?

Wie wirken sich SSL-„Signaturen

6

Obwohl ich keine Probleme damit habe, mich bei den Mitgliedern zu entschuldigen (:slightly_smiling_face:), möchte ich dieses Szenario unbedingt vermeiden, da ich einige nachteilige Nebeneffekte sehe:

  1. Mitglieder melden sich nicht mehr an und sind in Zukunft weniger bereit, am Forum teilzunehmen.
  2. Mitglieder vergessen ihr Passwort und benötigen Hilfe bei der Wiederherstellung.
  3. Mitglieder vergessen ihr Passwort und erstellen neue Konten, wodurch viele „Zombie-Konten
7

Ich weiß, dass meine Forensitzungen definitiv eine Sicherung und Wiederherstellung überstanden haben. Ich bin mir wirklich nicht sicher, was hier los ist :frowning:

8

Sitzungs-Cookies werden mit einem zufällig generierten geheimen Schlüssel verschlüsselt, der standardmäßig in Redis gespeichert wird. Redis-Daten sind nicht in einem Backup enthalten, sodass beim Wiederherstellen der Site auf einem neuen Server ein neuer geheimer Schlüssel generiert wird.

Du kannst den geheimen Schlüssel manuell über eine Umgebungsvariable DISCOURSE_SECRET_KEY_BASE in deiner app.yml-Datei festlegen. Um Sitzungen zu erhalten, könntest du beispielsweise so vorgehen:

  1. Gib auf deinem bestehenden Server die Konsole ein und finde den geheimen Schlüssel in Redis:

    pry(main)> GlobalSetting.safe_secret_key_base
=> "5fb9dc98be368599e0a..."

  2. Füge DISCOURSE_SECRET_KEY_BASE im Abschnitt env: deiner app.yml auf dem alten Server hinzu, verwende den in Schritt (1) gefundenen Wert und baue die App neu. Theoretisch sollte Discourse nun den Wert aus der app.yml verwenden und die Benutzersitzungen bleiben erhalten. Du kannst überprüfen, ob die Umgebungsvariable verwendet wird, indem du folgenden Befehl ausführst:

    GlobalSetting.secret_key_base

  3. Stelle sicher, dass die app.yml auf dem neuen Server denselben SECRET_KEY_BASE enthält. Beim Wiederherstellen des Backups sollten die Benutzersitzungen erhalten bleiben.

Ich habe diesen Ablauf nicht getestet. Wenn du ihn für ein Produktionsforum verwenden möchtest, teste ihn bitte zuerst!

Nebenbemerkung: Du solltest den geheimen Schlüssel auf keinen Fall zwischen mehreren Discourse-Instanzen teilen. Wer den geheimen Schlüssel besitzt, kann Sitzungs-Cookies auf einer Site entschlüsseln und manipulieren, was schwerwiegende Sicherheitsfolgen haben kann.

9

Ausgezeichnet – das werde ich in einer Sandbox-Instanz ausprobieren. Ich melde mich, falls es funktioniert oder nicht :slight_smile:

Verstanden. Ich überlege gerade, ob es sinnvoll wäre, einen Feature-Wunsch für eine Option zur Exportierung dieses Schlüssels in Backups einzureichen. Für mich wäre der Verlust aller Sitzungen auf einer Seite ein „sehr schlechtes Ereignis“, da es mehrere tausend Konten auf der Seite gibt. Die Übungsmigration hat dieses Problem aufgezeigt, aber ich nehme an, wenn die Maschine oder die Docker-Instanz aus irgendeinem Grund verloren geht, wäre auch der Schlüssel verloren, und wir stünden vor dem gleichen Verlust der Sitzungen.

Eine kurze Anmerkung zu diesem „Feature“ im Migrations-Topic wäre ebenfalls angebracht: Move your Discourse Instance to a Different Server

10

Es ist ein heikler Balanceakt zwischen Sicherheit und Benutzerfreundlichkeit.

Im Moment hat jemand, der ein Discourse-Backup stiehlt, zwar Zugriff auf alle Daten des Forums, kann sich aber nicht am Live-Forum anmelden. Passwörter sind gehasht, API-Schlüssel sind gehasht und Session-Cookies sind verschlüsselt.

Wenn wir den geheimen Schlüssel in das Backup aufnehmen würden, könnte jeder, der ein Backup besitzt, Zugriff auf das Live-Forum erlangen und Phishing, Betrug usw. durchführen.

Das klingt großartig! Wir sind absolut offen dafür, hier auf Meta einen Thread zu erstellen, der erklärt, wie man von einem Redis-geheimen Schlüssel auf einen app.yml-geheimen Schlüssel migriert. Dieser könnte im Thread „Auf einen anderen Server umziehen

11

Meiner bescheidenen Meinung nach sollte auch die Sicherheit der Standard-Backups verbessert werden. Zwar sind Passwörter und Sitzungen möglicherweise gehasht und geschützt, doch es könnte eine Menge anderer Daten in privaten Nachrichten und Ähnlichem enthalten sein, die weiterhin vertraulich bleiben sollten. Besonders zu beachten ist, dass wir in unserem Community-Forum die Nutzer ermutigen, private Nachrichten zum Austausch von Kontaktdaten und zur Vereinbarung von Verkäufen oder Abholungen zu nutzen, anstatt Telefonnummern und Adressen an öffentlichen Stellen zu veröffentlichen.

Mein Ansatz bei Backups besteht darin, die Instanz zu betreten, ein Backup zu erstellen und dieses anschließend sofort mit einem öffentlichen Schlüssel mittels GPG zu verschlüsseln. Dadurch ist das Backup für jeden unbrauchbar, der nicht über den entsprechenden privaten Schlüssel verfügt, den ich außerhalb des Servers speichere und durch eine Passphrase schütze.

Das gesagt: Wenn der geheime Schlüssel für Sitzungen sich nicht ändert, muss er nur einmal gesichert werden. Eine einfache Prozedur dafür ist also alles, was benötigt wird – und hoffentlich ist das das, was Sie oben skizziert haben.

Ich werde es versuchen und sehen, ob ich das Thema für Sie erstellen kann :slight_smile:

12

Sehr hilfreich, @david, danke!

13

Discourse bietet keine privaten Nachrichten an; die Funktion heißt Persönliche Nachrichten. Dieser Unterschied ist sehr wichtig, da es keinen Hinweis auf Privatsphäre gibt.

Administratoren können bereits jede PN auf der Seite lesen, es sei denn, Verschlüsselung wird verwendet.

14

Guter Punkt. Aber das ändert nichts daran, dass Mitglieder private Nachrichten nutzen können, um persönliche Daten auszutauschen oder Dinge, die sie nicht öffentlich zugänglich machen möchten. Daher ist es wichtig, diese Daten so weit wie vernünftig möglich zu schützen.

Ja, wir müssen auch den Administratoren jeder Website vertrauen, die wir nutzen, auch auf Seiten wie ProtonMail.

15

Etwas vom Thema abwegig… aber du könntest an Discourse Encrypt (deprecated) für wirklich ‘private’ Nachrichten interessiert sein. Geklonte oder gestohlene Backups verschlüsselter PMs wären für einen Angreifer nicht lesbar.

(obwohl, wie du sagtest, immer noch davon ausgegangen wird, dass die Administratoren vertrauenswürdig sind)

16

@david – könntest du bitte den folgenden Beitrag prüfen und, falls in Ordnung, aufteilen und nach howto verschieben? (Ich kann dort kein neues Thema erstellen. Außerdem hat Akismet den Beitrag gerade versteckt, das muss auch noch behoben werden :blush: )

18

@david – vielen, vielen Dank für die Lösung und den Rat. Ich hoffe, das hilft auch anderen – für uns ist es definitiv eine Erleichterung, dass wir migrieren und die Sitzungen beibehalten können :partying_face: