Salut Penar,
peut-être devons-nous d’abord clarifier les détails de ma configuration. Elle est un peu différente du déploiement standard.
- un répartiteur de charge central (https://www.haproxy.org/) agissant comme accélérateur SSL pour différents services Web (pas seulement pour Discourse). L’accès à partir d’Internet à l’un de ces services n’est autorisé que via https. Le passage de http à https est effectué sur le répartiteur de charge lui-même, voir Redirect HTTP to HTTPS in a Few Easy Steps with HAProxy pour référence)
- haproxy transfère les requêtes frontales vers le backend sur un réseau privé (10.x.x.x) sans chiffrement. Ce trafic se termine sur un nginx local sur l’hôte docker.
- nginx transfère les requêtes vers le socket http du conteneur web_only avec
proxy_pass ``http://unix``:/mnt/data/discourse/shared/web-only/nginx.http.sock
(J’utilise une configuration à deux conteneurs avec web_only.yml et data.yml). Voir templates/web.socketed.template.yml pour référence
Je n’ai pas besoin de SiteSetting.force_https, car tout le chiffrement https est effectué en dehors du conteneur Discourse. J’utilise déjà OAuth basé sur le plugin Discourse OpenID Connect (OIDC) et avec mon propre IDP. Le plugin Discourse OIDC contient un paramètre pour le document de découverte « well-known » OpenID Connect. Dans mon cas : https://login.netzwissen.de/realms/netzwissen/.well-known/openid-configuration
Si Discourse ID implémentait quelque chose de similaire pour le lien entre l’instance de conteneur Discourse et l’IDP Discourse ID, il n’y aurait aucun problème. Comme « Discourse ID » utilise un IDP fixe, une telle « URL bien connue » pourrait même être codée en dur, y compris le préfixe https.