Site déplacé derrière un proxy, favicon et en-tête ne utilisant plus HTTPS

Soutien
1

J’ai depuis déplacé mon instance Discourse entre des serveurs, et elle tourne maintenant derrière un proxy inverse avec terminaison SSL.

Cependant, l’image d’en-tête et le favicon ne sont pas demandés en HTTPS et sont bloqués. J’ai essayé de régler “force https” sur activé, mais cela n’a pas aidé.

image

2

Votre proxy fournit-il un en-tête X-Forwarded-Proto ? (Il devrait).

3

Votre proxy fournit-il un en-tête X-Forwarded-Proto ? (Il devrait l’être).

Oui, c’est le cas.

4

J’ai rencontré le même problème. J’ai une instance Discourse derrière HAProxy avec une terminaison SSL. La solution est assez simple, mais pas évidente :

  1. Assurez-vous d’abord que « forcer HTTPS » est activé dans les paramètres (allez dans Paramètres et filtrez par « forcer HTTPS »).
  2. Allez dans Paramètres > Identité visuelle > et téléchargez à nouveau vos logos.
  3. Tout devrait maintenant utiliser HTTPS (n’oubliez pas d’actualiser votre navigateur).

(Je pense qu’il s’agit peut-être d’un bug dans Discourse)

5

Bonjour,

Je souhaitais revenir sur cette problématique. En effet, je rencontre le même problème et je ne peux pas activer force_https à true car il est impossible de se connecter (erreur inconnue lors de la connexion).

Comment pouvons-nous forcer le logo à être référencé via une requête HTTPS et non HTTP ?
Ne devrait-ce pas être simple ?

Un grand merci pour votre retour (j’ai passé de nombreuses heures de mon côté à tenter de résoudre ce problème).

6

Vous devrez modifier le paramètre de site force_https en vous connectant au serveur via SSH et en entrant la ligne de commande Ruby. Des sujets howto expliquant comment procéder sont disponibles ici.

7

Merci pour votre réponse. Mon message était certainement peu clair. En fait, je parviens à modifier force_https en utilisant la commande Rails, sans problème. Donc, pour être plus précis :

Jusqu’à la dernière mise à niveau que j’ai effectuée il y a quelques jours et qui nécessitait de reconstruire le conteneur Docker, j’avais une solution entièrement fonctionnelle avec force_https activé (true) et en appliquant le correctif suivant dans la section server du fichier de configuration d’Nginx afin d’obtenir une connexion valide :

  if ($http_x_forwarded_proto = 'http'){
    return 301 https://$host$request_uri;
  }

Cela fonctionnait. Cependant, depuis la mise à niveau, le même correctif ne me permet plus de me connecter, affichant l’erreur bien connue « Unknown error ».

J’ai obtenu la trace suivante depuis le journal de production :

 Started POST "/session" for 193.134.222.4 at 2020-05-14 19:24:40 +0000
 Processing by SessionController#create as */*
 Parameters: {"login"=>"rossierd", "password"=>"[FILTERED]", "second_factor_method"=>"1", "timezone"=>"Europe/Zurich"}
 Can't verify CSRF token authenticity.
 Rendering text template
 Rendered text template (Duration: 0.0ms | Allocations: 1)
 Filter chain halted as :verify_authenticity_token rendered or redirected
 Completed 403 Forbidden in 2ms (Views: 0.7ms | ActiveRecord: 0.0ms | Allocations: 1101)

Sachez que notre conteneur Discourse s’exécute dans une machine virtuelle accessible via HTTPS.

Auriez-vous une idée de la cause de ce changement de comportement avant et après la mise à niveau ?

Pour l’instant, j’ai désactivé force_https en le passant à false. Tout fonctionne bien, sauf le logo en haut à gauche (logo de la marque) qui n’apparaît pas correctement car il est référencé via une requête http://…

Au passage, voici l’URL de notre site : https://discourse.heig-vd.ch

8

De plus, j’ai également trouvé le paramètre de site suivant qui contient l’URL coupable :
SiteSetting.site_favicon_url (un autre est SiteSetting.site_apple_touch_icon) avec la valeur « http://…jpeg ».
Cependant, il ne semble pas évident de modifier cette valeur avec une simple commande Rails, comme nous le faisons par exemple pour force_https…

9

S’il vous plaît, une aide sur ce sujet ?

10

Vous les avez définis via l’assistant de configuration. Relancez l’assistant de configuration et téléchargez à nouveau les images.

11

J’ai configuré les images de cette manière. J’ai relancé l’assistant, mais avec le même résultat à la fin :frowning:
Je suppose que le téléchargement des images n’a pas d’impact sur la façon dont elles sont référencées ; c’est plutôt lié à la génération de la page web.

12

Eh bien, après tant de tentatives infructueuses, j’ai enfin trouvé comment avoir une connexion valide avec force_https=true.

Dans l’environnement Docker, j’ai patché /etc/nginx/conf.d/discourse.conf comme suit :

…
location @discourse {
limit_conn connperip 20;
limit_req zone=flood burst=12 nodelay;
limit_req zone=bot burst=100 nodelay;
proxy_set_header Host $http_host;
proxy_set_header X-Request-Start “t=${msec}”;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto https; # $thescheme; ← Ce que j’ai modifié
proxy_pass http://discourse;
}
…

Et cela ne fonctionne que dans cette section, du moins avec mon environnement.

Ça marche super bien maintenant !