Kein Login nach Wiederherstellung eines Discourse Backups auf einem neuen Server möglich

Unterstützung
1

Hallo,

ich habe ein Discourse-Backup auf einer neuen VM wiederhergestellt.
Die Wiederherstellung selbst scheint zu funktionieren. Ich sehe die korrekte Start-GUI.

Wenn ich mich jedoch einzuloggen versuche, erhalte ich einen unbekannten Fehler:

Processing by UsersController#create as */*
  Parameters: {"name"=>"Istvan XXXXXXX", "email"=>"istvan.XXXXXXXX@mailbox.org", "password"=>"[FILTERED]", "username"
=>"Istvan", "password_confirmation"=>"[FILTERED]", "challenge"=>"6662a14f4549a786ed0f37XXXXXX", "timezone"=>"Eur
ope/Berlin"}
Filter chain halted as :respond_to_suspicious_request rendered or redirected
Completed 200 OK in 3ms (Views: 0.2ms | ActiveRecord: 0.0ms | Allocations: 1007)
Started POST "/login" for 172.17.0.1 at 2021-10-13 13:37:31 +0000
Processing by StaticController#enter as HTML
  Parameters: {"username"=>"Istvan", "password"=>"[FILTERED]", "redirect"=>"/u/account-created"}
Redirected to http://discourse.XXXXXXXXX/u/account-created
Completed 302 Found in 2ms (ActiveRecord: 0.0ms | Allocations: 512)
Started GET "/u/account-created" for 172.17.0.1 at 2021-10-13 13:37:31 +0000
Processing by UsersController#account_created as HTML
  Rendered default/empty.html.erb within layouts/application (Duration: 0.1ms | Allocations: 11)
  Rendered layout layouts/application.html.erb (Duration: 60.6ms | Allocations: 36879)
Completed 200 OK in 81ms (Views: 62.1ms | ActiveRecord: 0.0ms | Allocations: 39906)
Started GET "/session/csrf" for 172.17.0.1 at 2021-10-13 13:37:48 +0000
Processing by SessionController#csrf as JSON
Completed 200 OK in 4ms (Views: 2.0ms | Allocations: 602)
Started POST "/session" for 172.17.0.1 at 2021-10-13 13:37:48 +0000
Processing by SessionController#create as */*
  Parameters: {"login"=>"Istvan", "password"=>"[FILTERED]", "second_factor_method"=>"1", "timezone"=>"Europe/Berlin"
}
Can't verify CSRF token authenticity.
  Rendered text template (Duration: 0.0ms | Allocations: 1)
Filter chain halted as :verify_authenticity_token rendered or redirected
Completed 403 Forbidden in 5ms (Views: 0.7ms | Allocations: 897)

image
image611×592 37 KB

Haben Sie eine Idee, wie ich dieses Problem lösen kann?

Viele Grüße

I.

2

versuche, dein Passwort zurückzusetzen

3

Ich habe es ausprobiert, es funktioniert jedoch nicht …

image
image800×432 31 KB

Ich vermute, dass E-Mail-Nachrichten in der alten Installation deaktiviert waren (ich habe das Backup davon wiederhergestellt).

Ich.

4

Versuchen Sie, über die Konsole zu prüfen, ob force_https aktiviert ist:

SiteSetting.force_https

Falls der Wert false ist, setzen Sie ihn auf true:

SiteSetting.force_https = true

5

Meinst du innerhalb des Docker-Containers oder im VM-Bash?

6

Innerhalb von Docker. Führe dies in deiner VM aus

cd /var/discourse/
./launcher enter app
rails c
7

Vielen Dank, es war jedoch bereits „true":

image

Vielleicht muss es auf „false" gesetzt werden (ich habe kein Zertifikat) ODER wir müssen die richtige Domain verwenden (sie ist noch nicht „CNAMEd").

HTTPS ist in der YAML-Datei nicht aktiviert.

8

Warum nicht? Let’s Encrypt stellt dir kostenlos eines zur Verfügung.

Wenn du versuchst, eine IP-Adresse ohne Hostnamen zu verwenden, liegt das daran. Du musst einen Hostnamen verwenden.

9

Wenn du HTTPS nicht verwendest, sollte es tatsächlich auf „false" gesetzt werden.

10

Die Domain des „produktiven" Systems ist „https://deinbalkonnetz.de" (gehostet bei @discourse.). Wir haben diese auf eine interne VM verschoben, die weiterhin die Domain „discourse.itas-karlsruhe.de" besitzt. Diese Domain (ohne HTTPS-Unterstützung) wird nach wie vor in der app.yml verwendet.

In welcher Reihenfolge sollte Discourse verschoben werden?

#1 Weiterleitung der produktiven Domain an die VM?
#2 Ändern der app.yml auf die endgültige Domain UND gleichzeitig Aktivierung von Let’s Encrypt?

Bitte bestätigen Sie!

Vielen Dank.

I.

11

Wenn du das Hosting von discourse.org verlässt, solltest du zuerst dein Abonnement kündigen, damit Uploads in dein Backup aufgenommen werden. Andernfalls wird dein Backup lediglich auf Uploads auf deren S3/CDN verweisen.

Ich empfehle dir, deine Tests auf einem Server mit einer öffentlichen IP-Adresse durchzuführen oder zumindest auf einem mit einem gültigen HTTPS-Zertifikat (was auf einer privaten IP-Adresse schwieriger zu konfigurieren ist).

Wenn du bereit bist zu wechseln, musst du die DNS-Einträge für deinen Server ändern und neu erstellen, um das Let’s Encrypt-Zertifikat zu erhalten. Während die DNS-Änderungen wirksam werden, befindest du dich für eine Weile in einer Übergangsphase.

12

Ok. Vielen Dank.

Wenn du das Hosting von discourse.org verlässt, solltest du zuerst dein Abonnement kündigen, damit Uploads in dein Backup aufgenommen werden. Andernfalls wird dein Backup nur auf Uploads auf deren S3/CDN verweisen.

Ich habe ein neues Backup angefordert …

Ich empfehle, deine Tests auf einem Server mit einer öffentlichen IP-Adresse durchzuführen oder zumindest auf einem mit einem gültigen HTTPS-Zertifikat (was bei einer privaten IP schwieriger zu konfigurieren ist).

Ich werde HTTPS in „rail c" deaktivieren, nur um mich einloggen zu können. Nach dem Einloggen prüfe ich, ob das Lets-Encrypt-Add-on aktiviert ist (oder muss dies über app.yml erfolgen?). Falls es aktiviert ist, aktiviere ich HTTPS für die temporäre Domain. Wenn alles funktioniert, leiten wir die finale Domain auf die VM um und bauen die App mit dieser Domain neu auf.

Ich denke, das ist ein geeigneter Fahrplan … oder?

13

Hallo,

nach der Deaktivierung von HTTPS über SiteSetting.force_https = false war die Seite wieder erreichbar, und ich konnte mich als Site-Administrator anmelden.

Ich habe Let’s Encrypt gemäß den beschriebenen Schritten eingerichtet:
(Set up HTTPS support with Let's Encrypt)

Nach dem Neuaufbau der Seite hat jedoch nichts funktioniert; keine Seite war im Browser erreichbar …

Gibt es eine Möglichkeit zu prüfen, was schiefgelaufen ist?

Viele Grüße
I.