Am einfachsten war es für mich, ein zusätzliches Label in Discourse’s app.yml zu setzen, um meinem Traefik mitzuteilen, dass es einen X-Forwarded-Proto: https Header hinzufügen soll, aber dann überschrieb nginx diesen Parameter mit seiner eigenen Version.
Und Discourse’s nginx-Konfiguration spielt hier eine Rolle:
Dort versucht Discourse, das Protokoll aus der ursprünglichen Anfrage zu erraten (die in meinem Setup immer Plain-Text ist, da das Traefik sendet). Und verwendet dies dann, um den X-Forwarded-Proto mehrmals zu setzen.
Am Ende habe ich meine containers/app.yml bearbeitet, um diese Header auf https zu fixieren:
run:
- exec: echo "Beginning of custom commands"
## Wenn Sie die 'Von'-E-Mail-Adresse für Ihre erste Registrierung festlegen möchten, kommentieren Sie die Zeile aus und ändern Sie sie:
## Nachdem Sie die erste Registrierungs-E-Mail erhalten haben, kommentieren Sie die Zeile wieder aus. Sie muss nur einmal ausgeführt werden.
# - exec: rails r "SiteSetting.notification_email='no-reply@forum.cabana.network'"
- replace:
filename: "/etc/nginx/conf.d/discourse.conf"
from: /# attempt to preserve the proto, must be in http context\nmap \$http_x_forwarded_proto \$thescheme {\n default \$scheme;\n "~https$" https;\n}/\n
to: |
# force https scheme so Discourse generates HTTPs links and redirects (ie, `/login`)
- replace:
filename: "/etc/nginx/conf.d/discourse.conf"
from: "$thescheme"
global: "true"
to: "https"
- exec: echo "End of custom commands"
Noch einmal, ich denke, wenn es eine force_https-Einstellung gäbe, sollte Discourse-the-rails-app diese respektieren, unabhängig davon, was der Reverse-Proxy oder andere Parteien handhaben oder nicht.