Nous avons une installation Discourse maintenue depuis plusieurs années, actuellement sur la dernière version (2.4.0beta2) avec la dernière image Docker, exposée sur une adresse IP publique, sans proxy ni autre élément devant, avec des certificats LetsEncrypt.
Parfois, l’adresse IP d’enregistrement de l’utilisateur et la dernière adresse IP fonctionnent parfaitement, parfois non. Je ne vois aucune logique à cela. Par exemple, voici un utilisateur créé il y a 7h, avec des adresses absurdes :
Et ainsi de suite : sur certains utilisateurs, c’est bon, sur d’autres, non. Avez-vous des idées sur ce qui se passe ici ?
Une chose qui me frappe en y regardant de plus près est que ces utilisateurs pourraient arriver via IPv6, car je n’ai jamais vu d’adresse IPv6 dans ces champs. Discourse ne prend-il pas en charge IPv6 ? Le proxy Docker ne comprend-il pas ou ne transmet-il pas les informations pertinentes ? Autre chose ?
Discourse le prend en charge sans aucun doute, mais vous devrez configurer votre serveur et tout ce qui se trouve devant lui afin qu’IPv6 soit fonctionnel, etc.
IPv6 est très fonctionnel, et nous utilisons la configuration recommandée des images Docker avec les modèles web + données. Il n’y a rien d’autre devant. Qu’est-ce que nous devrions ajuster ?
Sachez que notre fichier yml de conteneur existe depuis quelques années, bien qu’il inclue les derniers modèles et que les images elles-mêmes soient reconstruites fréquemment. Est-ce que quelque chose a pu changer en cours de route ?
Difficile à dire. Je viens d’auditer les 8 derniers nouveaux utilisateurs inscrits sur talk.commonmark.org, qui est une installation standard par défaut, et ils avaient tous des adresses IPv4 valides pour l’adresse IP de dernière connexion et l’adresse IP d’inscription (parfois les deux différaient, également).
Je sais que si des comptes utilisateurs arrivent via SSO ou d’autres canaux inhabituels, cela peut affecter les adresses IP qui y sont signalées. Tous ces utilisateurs dont vous parlez sont-ils des inscriptions régulières via la fenêtre de dialogue standard de création de compte dans Discourse ?
Alors, je suis sûr que cela ne présentera pas le problème d’afficher localhost au lieu des adresses IPv6 pour les utilisateurs qui se connectent via IPv6. Cela ne signifie pas que le problème n’existe pas.
Le problème n’existe pas sur l’hébergement officiel de Discourse, du moins pas sur celui-ci, qui est compatible IPv6. Je ne vois pas non plus de problèmes sur une installation standard chez un hébergeur de colocation au hasard. Je ne sais pas quoi d’autre vous dire, si ce n’est que vous n’avez pas répondu à ma question, qui est plutôt importante.
Je ne doute pas que cela fonctionne dans votre hébergement, mais vous n’utilisez pas la configuration Docker « standard » que la plupart des utilisateurs adoptent, je suppose ? Je veux dire, je suis sûr que c’est possible de le faire fonctionner avec un proxy configurant les bons en-têtes, etc. La question est simplement de savoir si la configuration par défaut le fait et, si ce n’est pas le cas, si nous pouvons le configurer pour qu’il le fasse.
Je suis presque certain que vous devez ajouter un élément à votre app.yml indiquant à nginx de reconnaître votre adresse IPv6 et de transmettre l’adresse du client. Cependant, je n’ai pas encore réussi à déterminer comment faire. Les sujets traitant de l’exécution d’un proxy inverse contiennent des exemples IPv6 qui donnent des indices.
Cela figure sur ma liste de choses à résoudre, mais cette liste est plutôt longue. J’ai fini par désactiver IPv6, probablement à cause de ce problème, mais peut-être aussi en raison de certaines méconnaissances d’IPv6.
(Jeff, vous pouvez obtenir un bloc IPv6 routé, mais vous devez en faire la demande et ensuite configurer vos hôtes pour l’utiliser.)
Je pense que le proxy inverse externe est la clé : je ne pense pas que ce problème soit résoluble, ou du moins pas facilement, uniquement depuis le conteneur Docker.
Je l’ai résolu en faisant écouter le conteneur Discourse sur une socket Unix et en le plaçant derrière un Caddy sur la même machine (en dehors de Docker). La configuration de Caddy est triviale, inclut Let’s Encrypt, et maintenant cela fonctionne comme prévu, y compris pour l’IPv6.