J’espère que quelqu’un pourra me donner des conseils, je vous en serais reconnaissant. Je vais vous expliquer la situation.
J’ai installé Discourse à plusieurs reprises sur mon domaine, hostballs[.]com. À chaque fois, la visite de www[.]hostballs[.]com redirigeait correctement vers hostballs[.]com, car le certificat LetsEncrypt couvrait les deux versions, avec et sans www. C’est ce que je considère comme le comportement par défaut et standard de Discourse avec sa mise en œuvre de LE.
Actuellement, ma nouvelle installation de Discourse configure SSL pour le site sans www (tel que configuré dans l’URL), mais elle ne couvre pas www. Cela signifie que toute personne visitant www[.]hostballs[.]com ne sera pas redirigée, mais verra plutôt une erreur SSL. Étant donné que je sais que le comportement par défaut diffère de cela, et que l’installation de Discourse est trop contrôlée pour que je veuille simplement me rendre à certbot et tout faire manuellement (cela rendra-t-il les mises à jour régulières amusantes ?), je ne suis pas sûr de la meilleure voie à suivre.
En essayant de résoudre ce problème, j’ai commenté les modèles ssl et LE, ainsi que l’adresse e-mail LE, dans app.yml. J’ai ensuite supprimé les répertoires letsencrypt et ssl de /shared/standalone. J’ai reconstruit le site sans SSL, puis réactivé ces options dans app.yml et reconstruit à nouveau pour générer de nouveaux certificats et configurations SSL. Bien que cela ait réussi, cela n’a pas corrigé le problème www.
Quelqu’un d’autre a-t-il déjà fait face à une situation similaire et trouvé une solution ?
Si les conseils ci-dessus vous semblent trop intimidants, vous pouvez également configurer une redirection DNS simple. La plupart des registres l’offrent.
Discourse ne peut pas être publié sous plusieurs URLs ; l’enregistrement racine (sans www) et l’enregistrement « A » www sont des adresses distinctes. Une fois que vous avez désigné un nom de domaine complet (FQDN) pour votre site, toute adresse supplémentaire doit être gérée via une redirection.
Si aucune des suggestions déjà proposées ne vous convient, vous pouvez choisir d’utiliser www.example.com et utiliser http://forcewww.com/ pour rediriger vers le site avec www.
Merci les amis. Laissez-moi passer en revue quelques détails qui pourraient aider quelqu’un d’autre à l’avenir.
Tout a commencé lorsqu’un utilisateur m’a signalé que la visite de www ne fonctionnait pas et affichait une erreur de certificat. En accédant directement au lien https qu’il avait fourni dans le fil de signalement, j’ai rencontré le même problème. Par le passé, lorsque j’utilisais www, je n’avais pas rencontré ce problème, mais j’étais plutôt redirigé vers le domaine racine sans difficulté. Cela m’a conduit à conclure que mon installation, après une migration récente, était en quelque sorte défectueuse et ne se comportait pas selon les caractéristiques par défaut d’une nouvelle installation de Discourse.
J’ai donc installé une copie fraîche de Discourse sur un nouveau domaine pour démontrer que www fonctionnait par défaut lors de l’utilisation du domaine racine. Je suis allé sur le domaine, puis j’ai édité l’URL dans ma barre d’adresse et ajouté « www. » au début. Il s’est redirigé vers le domaine racine sans problème, comme je m’y attendais. Ensuite, j’ai pensé essayer une dernière chose. J’ai saisi manuellement « https:// » avant. Il a alors échoué avec la même erreur de certificat.
Ainsi, ce qui m’a peut-être amené à supposer que la configuration pour www était un comportement par défaut dans l’implémentation de LE de Discourse, pourrait en fait être mon navigateur utilisant par défaut le port 80 tout en masquant la partie http/https de l’URL à ma vue pendant que je réécrivais l’URL dans la barre d’adresse.
C’est la meilleure évaluation que je puisse faire de la situation, du moins pour l’instant.
Solution la plus simple pour quelqu’un qui utilise son domaine racine et souhaite que www soit signé par LE pour une redirection HTTPS correcte, sans compliquer les choses ni utiliser un autre serveur web pour gérer la redirection :
Ouais, je ne vois pas de moyen d’y parvenir sans risquer que ça se brise lors des mises à jour. C’est simplement le lot de ceux qui ont des domaines dédiés à leurs communautés et qui n’aiment pas les sous-domaines inutiles.
Sauf à faire tourner un autre serveur web ailleurs, bien sûr.
Bon, je vois déjà une tentative qui a été arrêtée parce qu’un fichier a changé, ce qui a cassé la méthode utilisée pour le modifier dans app.yml :
Que nous modifiions un fichier directement ou que app.yml le modifie ensuite, une mise à jour risque de changer ce fichier et de casser votre méthode de modification, quoi qu’il arrive.
Mon point est que toute modification de ce modèle le fera à nouveau échouer. Une seule modification a rompu la méthode PUPS/hooks au cours des dernières années : l’ajout de la prise en charge de l’ECC.