La cosa più semplice per me è stata impostare un’etichetta aggiuntiva in app.yml di Discourse per dire al mio Traefik di aggiungere un’intestazione X-Forwarded-Proto: https, ma poi nginx sovrascriveva quel parametro con la propria versione.
E la configurazione nginx di Discourse gioca un ruolo qui:
Qui Discourse cerca di indovinare il protocollo dalla richiesta originale (che, nella mia configurazione, è sempre plain-text poiché è ciò che Traefik invia). E poi lo usa per impostare X-Forwarded-Proto più volte.
Alla fine, ho modificato il mio containers/app.yml per codificare queste intestazioni in https:
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='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"
Ancora una volta, penso che se ci fosse un’impostazione force_https, Discourse-the-rails-app dovrebbe rispettarla, indipendentemente da ciò che il reverse proxy o altre parti gestiscono o meno.