Ciao Penar,
forse dobbiamo prima chiarire i dettagli della mia configurazione. È un po’ diversa rispetto alla distribuzione standard.
- load balancer centrale (https://www.haproxy.org/) che funge da acceleratore SSL per diversi servizi web (non solo per Discourse). L’accesso da Internet a uno qualsiasi di questi servizi è consentito solo tramite https. Il passaggio da http a https viene eseguito sul load balancer stesso, vedi Redirect HTTP to HTTPS in a Few Easy Steps with HAProxy come riferimento)
- haproxy inoltra le richieste frontend al backend su una rete privata (10.x.x.x) senza crittografia. Questo traffico termina su un nginx locale sull’host docker.
- nginx inoltra le richieste al socket http del container web_only con
proxy_pass ``http://unix``:/mnt/data/discourse/shared/web-only/nginx.http.sock
(sto usando una configurazione a due container con web_only.yml e data.yml). Vedi templates/web.socketed.template.yml come riferimento
Non ho bisogno di SiteSetting.force_https, poiché tutta la crittografia https viene eseguita al di fuori del container Discourse. Utilizzo già OAuth basato sul plugin Discourse OpenID Connect (OIDC) e con il mio IDP. Il plugin Discourse OIDC contiene un’impostazione per il documento di discovery “well-known” di OpenID Connect. Nel mio caso: https://login.netzwissen.de/realms/netzwissen/.well-known/openid-configuration
Se Discourse ID implementasse qualcosa di simile per il collegamento tra l’istanza del container Discourse e l’IDP di Discourse ID, non ci sarebbero problemi. Poiché “Discourse ID” utilizza un IDP fisso, un tale “URL well-known” potrebbe persino essere codificato in modo fisso, incluso il prefisso https.