Est-ce que proxy_set_header X-Forwarded-Proto https; fonctionnerait simplement ?
La requête http/s provient du conteneur vers le serveur IDP pour Discourse ID sur Internet. Il n’y a aucune instance intermédiaire où je pourrais ajouter/modifier des en-têtes de requête.
Selon moi et en supposant que « Discourse ID » est juste un OAuth standard, la bonne façon serait soit
a) une option de configuration pour Discourse ID où je pourrais ajouter un point de terminaison de configuration « bien connu » qui contient toutes les valeurs de configuration OIDC requises, y compris le préfixe « https://… ».
b) la même chose, mais déjà codée en dur dans le code
Je suis toujours en train de réfléchir aux détails techniques de Discourse ID…
Vous pouvez consulter les détails de l’ID Discourse dans notre code, le protocole que nous utilisons est entièrement disponible dans notre dépôt Github. La seule différence avec d’autres implémentations OAuth est que nous enregistrons automatiquement une instance. Et lors de cet enregistrement automatique, nous nous assurons que l’instance demandant à s’enregistrer est bien celle qu’elle prétend être et qu’elle utilise https (à notre époque, aucune instance Discourse ne devrait utiliser http://).
Les erreurs http que j’ai partagées ci-dessus m’indiquent que votre site n’est pas correctement configuré.
Pouvez-vous vérifier la sortie de ce qui suit via la console :
Discourse.base_url
SiteSetting.force_https
Si vous obtenez une URL http:// de la première commande et false de la seconde, vous pourriez vouloir définir SiteSetting.force_https = true et voir si cela résout le problème. (Cela pourrait également casser des choses si la configuration est incorrecte ailleurs, cependant. Attention.)
1 « J'aime »
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.
Thomas, désolé, je ne peux pas vraiment vous aider avec votre configuration spécifique. Tout ce que je peux dire, c’est que quelque chose dans votre instance est incorrect.
Eh bien, la console JS de votre site ne pense pas que le chiffrement https en dehors du conteneur couvre tout. Ces avertissements JS que j’ai partagés ci-dessus sont les symptômes d’un problème similaire que vous rencontrez avec l’ID, Discourse lui-même dans votre configuration pense qu’il fonctionne en http et c’est un problème, car il générera des URL en http dans certains cas.
2 « J'aime »
Veuillez m’excuser, vraiment désolé :
J’ai comparé les paramètres de notre instance productive (PROD) avec ceux de l’instance DEV. Seule l’instance DEV avait désactivé le paramètre force_https. Et cela n’a fonctionné que parce que nous avons l’accélérateur SSL haproxy devant elle.
J’ai maintenant activé le SiteSetting.force_http dans l’instance DEV et Discourse ID fonctionne bien. Je vais donc également déployer Discourse ID sur notre instance PROD (forum.netzwissen.de).
Désolé pour la confusion.
3 « J'aime »
Pas de souci, content que ce soit résolu. Merci pour votre suivi !
2 « J'aime »