J’ai configuré des serveurs Discourse sur environ 5 instances et elles semblent toutes présenter un comportement étrange. Je ne sais pas s’il s’agit réellement d’un bug ou si d’autres personnes ont rencontré le même problème.
Étapes pour reproduire le problème
La configuration du serveur se déroule sans accroc.
L’assistant de configuration se passe bien : toutes les images sont téléchargées et affichées comme prévu.
L’utilisateur reçoit le lien d’inscription, clique dessus pour suivre, et l’inscription se déroule correctement.
(C’est ici que les choses se gâtent) : l’utilisateur se connecte et tous les logos du site sont cassés — seuls les titres textuels s’affichent.
L’utilisateur ne peut pas télécharger ou attribuer un avatar personnalisé.
Le certificat du site signale que le site n’est pas sécurisé.
Pour une raison inconnue, cela n’affecte QUE le navigateur utilisé pour l’inscription, et le taux d’échec est beaucoup plus élevé avec Chrome.
Dépannage
Nous avons conseillé aux utilisateurs de vider le cache et les cookies de leur navigateur — le problème persiste.
Nous avons demandé aux utilisateurs de réinstaller leurs navigateurs, principalement Chrome — le problème persiste.
Nous avons demandé aux personnes d’utiliser une identité alternative dans Chrome ou d’essayer un autre navigateur (Safari, Firefox, etc.) — cela fonctionne !
Nous n’avons absolument aucune idée de pourquoi le dernier point fonctionne et pourquoi l’identité d’inscription d’origine est affectée. Il ne serait pas tenable de demander à nos utilisateurs (environ 600 à 700) de se déconnecter de leur identité Chrome et de se reconnecter — si, pour une raison quelconque, c’est effectivement la solution.
Est-ce une installation standard de 30 minutes ? Ou y a-t-il quelque chose de personnalisé ici ?
Avez-vous activé force_https dans les paramètres du site pour voir si cela résout le problème ?
Je ne parviens pas à reproduire vos étapes dans mon bac à sable sur la dernière branche, il serait donc très utile si vous pouviez partager un lien vers l’une des instances concernées.
D’accord. Toutes les instances d’installation reçoivent leur certificat d’un proxy Nginx inverse qui n’est PAS la même machine. Est-ce que force_https fera toujours la différence ?
Donc ce n’est pas une installation standard. Vous avez dit que si.
Si Discourse se trouve derrière un correctement configuré proxy inverse, l’option force_https fera assurément la différence. Ce paramètre indique essentiellement à Discourse de charger toutes les ressources et les éléments statiques via HTTPS.
Ça l’a fait, d’ailleurs. Bloquez-moi. L’activation de force_https a résolu le problème d’image, MAIS cela a rendu impossible l’authentification depuis les navigateurs avec une nouvelle session. La session existante fonctionne bien, mais dès que vous vous déconnectez, vous ne pouvez plus revenir.
Je viens de le faire, j’ai déjà configuré efficacement tout mon bloc serveur comme le suggère l’article. C’est probablement pourquoi les sessions dans les profils alternatifs ou les navigateurs fonctionnent normalement après l’inscription/la connexion initiale.
Le seul élément où ma configuration diffère, c’est que je n’utilise pas templates.yml.
Non. Pas d’authentification externe. J’ai essayé en navigation privée. Rien n’y fait. Même résultat.
Cela doit venir du bloc serveur. J’investiguerai un peu plus tard.