Ce qui a été le plus facile pour moi, c’est d’ajouter une étiquette supplémentaire dans app.yml de Discourse pour dire à mon Traefik d’ajouter un en-tête X-Forwarded-Proto: https, mais ensuite nginx remplacerait ce paramètre par sa propre version.
Et la configuration nginx de Discourse joue un rôle ici :
Là, Discourse essaie de deviner le protocole de la requête d’origine (qui, dans ma configuration, est toujours en texte brut puisque c’est ce que Traefik envoie). Et l’utilise ensuite pour définir le X-Forwarded-Proto plusieurs fois.
Finalement, j’ai modifié mon containers/app.yml pour coder en dur ces en-têtes en 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"
Encore une fois, je pense que s’il existait un réglage force_https, Discourse-l’application-rails devrait le respecter, indépendamment de ce que le proxy inverse ou d’autres parties gèrent ou non.