Cependant, est-ce toujours le cas ? La redirection n’aidera pas dans mon cas (et je ne veux vraiment pas faire de réécritures fantaisistes de proxy inverse pour un cas d’utilisation simple et temporaire) : Dans mon cas, je veux installer un nouveau serveur discourse en parallèle de l’existant et avoir une vue de staging de ce serveur avec un nouveau nom. Cependant, le serveur devrait également accepter le nom officiel (pour le moment du basculement DNS ou lorsque les administrateurs utilisent un alias /etc/hosts). Cela améliorerait grandement la phase de staging.
Je pense que le problème principal actuel sont les URL CSP absolues qui empêchent cela de fonctionner (bien que comme elles vérifient déjà le protocole, elles devraient pouvoir être étendues pour vérifier les noms d’hôte d’une liste d’hôtes autorisés). Alors, est-ce disponible… entre-temps ?
Au fait, dans mon cas, je teste avec http, mais je pense que la configuration letsencrypt pour demander plusieurs certificats est déjà couverte ici, donc je pourrai le faire plus tard. (cela ne fonctionnera pas tant qu’il ne sera pas disponible sous le bon alias officiel de toute façon)
Au fait, je viens de remarquer que la reconstruction du conteneur de l’application avec un DISCOURSE_HOSTNAME différent ne fonctionne pas - je soupçonne que c’est aussi quelque part dans la base de données (mais cela ne peut pas être modifié dans les paramètres d’administration).
Ce qui rend d’autant plus important d’avoir une liste d’hôtes acceptés pour un tel scénario.
Si vous souhaitez que plusieurs noms soient résolus et que Discourse redirige vers le bon, vous êtes prêt pour http. Pour https, vous devrez obtenir un certificat pour tous les domaines. Je pense que Configurer Let’s Encrypt avec plusieurs domaines devrait vous aider.
Si vous souhaitez que le site ne se redirige pas vers lui-même, vous pouvez ajuster nginx pour qu’il n’effectue pas cette redirection. Je ne suis pas sûr de savoir comment vous expliquer comment le faire.
Le sujet du changement de nom d’hôte ne fonctionne pas de manière fiable pour moi (par exemple, malgré le remappage+recuisson, les émoticônes Twitter du message de bienvenue pointent vers le mauvais serveur) - je n’ai pas recherché pourquoi (je vous le ferai savoir). Au moins, ce n’est pas sans douleur.
La redirection pour mes cas d’utilisation ne fonctionne pas car elle redirigerait vers l’ancien serveur.
La configuration nginx n’a pas besoin d’être modifiée, elle n’est pas au courant du nom d’hôte. Mais le problème vient plutôt de l’application, par exemple les en-têtes CSP contiennent l’URL complète (aucune idée pourquoi).