CSRF-Login-Fehler nach Upgrade auf 2.5.0.beta4

Unterstützung
1

Nach dem Upgrade auf 2.5.0.beta4 sehe ich CSRF-Fehler im Produktionslog:

Processing by SessionController#csrf as JSON
Completed 200 OK in 1ms (Views: 0.1ms | ActiveRecord: 0.0ms | Allocations: 351)
Started POST "/session" for 127.0.0.1 at 2020-05-05 09:25:17 +0000
Processing by SessionController#create as */*
  Parameters: {"login"=>"admin", "password"=>"[FILTERED]", "second_factor_method"=>"1", "timezone"=>"Europe/Berlin"}
Can't verify CSRF token authenticity.
  Rendering text template
  Rendered text template (Duration: 0.0ms | Allocations: 1)
Filter chain halted as :verify_authenticity_token rendered or redirected
Completed 403 Forbidden in 2ms (Views: 0.7ms | Allocations: 1100)

Und Discourse Doctor zeigt Folgendes an:

========================================
Discourse 2.5.0.beta4
Discourse version at forum.netzwissen.de: Discourse 2.5.0.beta4
Discourse version at localhost: NOT FOUND
==================== DNS PROBLEM ====================
This server reports NOT FOUND, but forum.netzwissen.de reports Discourse 2.5.0.beta4 .
This suggests that you have a DNS problem or that an intermediate proxy is to blame.
If you are using Cloudflare, or a CDN, it may be improperly configured.

Frage: Der Server selbst hostet mehrere Dienste mit unterschiedlichen DNS-Namen. Vor Discourse steht ein HAProxy-Server, der die SSL-Terminierung übernimmt. Ich verstehe die Fehlermeldung nicht.

„Discourse version at localhost: NOT FOUND"

Könnte es sein, dass der CSRF-Fehler mit dieser Fehlermeldung zusammenhängt?

2

Discourse-doctor gibt nicht vor, eine komplexe Einrichtung wie deine diagnostizieren zu können. Es wird lediglich geprüft, ob der lokale Host und der DNS denselben Wert zurückgeben. Für deine Einrichtung ist es erwartungsgemäß, dass diese unterschiedlich sind.

Ich habe jedoch keine Hinweise auf dein tatsächliches Problem. Entschuldige.

3

Hallo,
ok, ich habe es mit einem anderen Konto getestet und erhalte dieselbe Fehlermeldung. Es scheint, als wären Logins jetzt vollständig blockiert, und der CSRF-Fehler könnte die Ursache sein…

Hast du Ideen für weitere Fehlersuche? Meine app.yml ist ziemlich Standard, außer dass:

expose:
  - "127.0.0.1:884:80"   # http

Eingehende Anfragen werden von einem HAProxy-Server an den Discourse-Container auf Port 884 weitergeleitet. SSL/HTTPS wird von HAProxy übernommen.

4

Beim Registrieren eines neuen Benutzers über OAuth2 (Google) erhalte ich ebenfalls einen CSRF-Fehler:

 Rendered common/_discourse_stylesheet.html.erb (Dauer: 0,4 ms | Zuordnungen: 206)
  Rendered application/_header.html.erb (Dauer: 0,3 ms | Zuordnungen: 142)
Completed 200 OK in 23 ms (Views: 20,4 ms | ActiveRecord: 0,0 ms | Zuordnungen: 4636)
Started GET "/latest.json?order=default" for 127.0.0.1 at 2020-05-05 11:43:08 +0000
Processing by ListController#latest as JSON
  Parameters: {"order"=>"default"}
Completed 200 OK in 30 ms (Views: 0,1 ms | ActiveRecord: 0,0 ms | Zuordnungen: 10224)
Started GET "/u/hp.json" for 127.0.0.1 at 2020-05-05 11:43:08 +0000
Processing by UsersController#get_honeypot_value as JSON
Completed 200 OK in 3 ms (Views: 0,1 ms | ActiveRecord: 0,0 ms | Zuordnungen: 1049)
Started GET "/session/csrf" for 127.0.0.1 at 2020-05-05 11:43:38 +0000
Processing by SessionController#csrf as JSON
Completed 200 OK in 1 ms (Views: 0,2 ms | ActiveRecord: 0,0 ms | Zuordnungen: 355)
Started POST "/auth/google_oauth2" for 127.0.0.1 at 2020-05-05 11:43:38 +0000
(google_oauth2) Setup endpoint detected, running now.
(google_oauth2) Request phase initiated.
Started GET "/auth/failure?message=csrf_detected" for 127.0.0.1 at 2020-05-05 11:43:38 +0000
Processing by Users::OmniauthCallbacksController#failure as HTML
  Parameters: {"message"=>"csrf_detected"}
  Rendering users/omniauth_callbacks/failure.html.erb within layouts/no_ember
  Rendered users/omniauth_callbacks/failure.html.erb within layouts/no_ember (Dauer: 0,1 ms | Zuordnungen: 20)
  Rendered layouts/_head.html.erb (Dauer: 11,7 ms | Zuordnungen: 3551)
  Rendered common/_discourse_stylesheet.html.erb (Dauer: 0,5 ms | Zuordnungen: 213)
  Rendered application/_header.html.erb (Dauer: 0,9 ms | Zuordnungen: 555)
Completed 200 OK in 19 ms (Views: 16,4 ms | ActiveRecord: 0,0 ms | Zuordnungen: 7652)
5

Ich habe nach dem Upgrade auf 2.5.0.beta4 exakt das gleiche Problem (Moved site behind proxy, favicon and header not using https anymore - #7 by rossierd).

Haben Sie das Problem bereits lösen können? Ich kann mir vorstellen, dass das Upgrade eine neue Version von nginx (oder dessen Konfiguration) mit sich brachte, die zu diesem Problem führt (aber das ist reine Spekulation ;-)).
Ich habe versucht, einen Weg zu finden, um CSRF in nginx zu deaktivieren (GitHub - gartnera/nginx_csrf_prevent: Prevent CSRF with nginx · GitHub), aber ich denke, nginx muss neu kompiliert werden, und ich weiß nicht, ob wir dafür die vollständige Entwicklungsumgebung von Discourse benötigen.

6

Leider ist das Problem hier immer noch nicht gelöst. Die Anmeldung schlägt mit „unbekannter Fehler

7

Versuchen Sie es hier: Moved site behind proxy, favicon and header not using https anymore - #12 by rossierd

Ich habe damit eine erfolgreiche Anmeldung erreicht, aber achten Sie darauf, wo Sie den Befehl proxy_pass patchen. Er funktioniert nur in location @discourse { .. }

8

Okay, nur zur Klärung: Wir sprechen über den **nginx in der „Container-Zoo

9

Ja, wenn du mit ‘zoo’ den Container meinst, auf dem Discourse läuft. Du kannst den Container mit ‘rails enter app’ betreten.

10

Wir haben hier weitere Fehlersuche durchgeführt: Das Problem beginnt am Nginx-Server innerhalb des Containers. Er versteht die Direktive proxy_pass nicht und stürzt daher scheinbar ab. Aber warum:

root@develd:/var/discourse# docker ps -a
CONTAINER ID        IMAGE                              COMMAND                  CREATED             STATUS                     PORTS                   NAMES
f8f6103a036d        local_discourse/app                "/sbin/boot"             35 seconds ago      Up 32 seconds              127.0.0.1:884->80/tcp   app
43406c37f403        discourse/base:2.0.20200512-1735   "ruby -e 'require 'y…"   2 hours ago         Created


docker exec -it f8f6103a036d /bin/bash

root@forum:/# tail -f /var/log/nginx/error.log
2020/06/08 19:05:03 [emerg] 288#288: "proxy_pass" directive is not allowed here in /etc/nginx/conf.d/discourse.conf:10

Ich verwende diese Nginx-Konfiguration in app.yml:

## Any custom commands to run after building
run:
  - exec: echo "Beginning of custom commands"
  ## If you want to set the 'From' email address for your first registration, uncomment and change:
  ## After getting the first signup email, re-comment the line. It only needs to run once.
  ## - exec: rails r "SiteSetting.notification_email='noreply-discourse@netzwissen.de'"
  - replace:
      filename: /etc/nginx/conf.d/discourse.conf
      from: "types {"
      to: |
        set_real_ip_from 127.0.0.0/24;
        real_ip_header X-Forwarded-For;
        real_ip_recursive on;
        proxy_set_header Host $http_host;
        proxy_set_header X-Request-Start "t=${msec}";
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto https; # $thescheme; <--- Was ich geändert habe
        proxy_pass http://discourse;
        types {
  - exec: echo "End of custom commands"
11

Ich denke, dass du dieses proxy_pass in deiner app.yml gar nicht brauchst. Meine Konfiguration sieht so aus:

  after_bundle_exec:
    # Das ist der Trick, um IP-Adressen an Discourse weiterzuleiten
    # Siehe https://meta.discourse.org/t/last-ip-address-and-action-dispatch-trusted-proxies/50098/3?u=pfaffman
    - replace:
        filename: /etc/nginx/conf.d/discourse.conf
        from: "types {"
        to: |
          set_real_ip_from 192.168.1.0/24;
          set_real_ip_from 172.18.0.0/24;
          set_real_ip_from 172.17.0.0/24;
          real_ip_recursive on;
          real_ip_header X-Forwarded-For;
          types {

Mein Code stammt jedoch möglicherweise noch aus der Zeit vor dem Wechsel zu Debian in den Containern.

Du könntest versuchen, diese Datei direkt im Container zu bearbeiten und nginx neu zu starten.

12

Um sicherzugehen: Bearbeiten Sie im Container selbst die Datei /etc/nginx/conf.d/discourse.conf und patchen Sie sie wie oben beschrieben. Starten Sie nginx anschließend wie folgt neu:

$ service nginx stop
$ service nginx start

und beobachten Sie, was passiert…

13

Jays Hinweis war korrekt: Ich habe einfach proxy_pass entfernt und dann hat es funktioniert. Die finale Konfiguration in app.yml lautet:

## Alle benutzerdefinierten Befehle, die nach dem Build ausgeführt werden sollen
run:
  - exec: echo "Beginn der benutzerdefinierten Befehle"
  ## Wenn Sie die E-Mail-Adresse im Feld 'Von' für Ihre erste Registrierung festlegen möchten, entfernen Sie das Kommentarzeichen und ändern Sie:
  ## Nachdem Sie die erste Anmelde-E-Mail erhalten haben, kommentieren Sie die Zeile erneut aus. Sie muss nur einmal ausgeführt werden.
  ## - exec: rails r "SiteSetting.notification_email='noreply-discourse@netzwissen.de'"
  - replace:
      filename: /etc/nginx/conf.d/discourse.conf
      from: "types {"
      to: |
        set_real_ip_from 127.0.0.1/24;
        real_ip_header X-Forwarded-For;
        real_ip_recursive on;
        proxy_set_header Host $http_host;
        proxy_set_header X-Request-Start "t=${msec}";
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto https; # $thescheme; <--- Das habe ich geändert
        types {
  - exec: echo "Ende der benutzerdefinierten Befehle"