Hello,
I tried using Force https and it seemed to work for me except it was causing login problems. However, the logos are loaded using http by default. They should use the // protocol and let the browser decide which one to use, right? Or maybe there is another solution I’m missing?
Thanks
Hi Eddie,
What version of Discourse are you running? In recent versions logos are uploaded via site settings, instead of being linked using a URL, so this should no longer be an issue.
Hi Joshua, We recently upgraded to v2.2.5. During the previous upgrade, before force https, I believe I deleted the post where the logos were uploaded and switched to the site settings. Everything was fine. Then with v2.2.5, I can’t get rid of the http:// part without force https. I tried reuploading, the wizard, even modifying the images so their hash was different. No luck
Sorry, now I’m confused. Is force_https enabled or not? Is there any possibility you’re overriding the uploaded logos via themes? If your force_https is enabled, and your logos are served via site settings, there should not be a mixed content warning. Are you able to share a link to your site so I can take a look?
It was enabled, thought the upgrade was over. Then our QA reports that logins are not working. so we disabled force https for now. You can test here //forum.y8.com
I checked the themes and didn’t spot anything that might cause this https problem. We mostly use stock, though it is an old stock theme.
Avec force_https désactivé, je ne peux pas tester cela. Nous nous appuyons sur ce paramètre pour garantir que les ressources sont servies via https et non http. Concernant le problème de connexion, il semble que vous utilisiez SSO ; assurez-vous donc que la redirection SSO depuis votre fournisseur pointe vers votre site via https:// et non http://. Une fois que vous aurez réactivé force_https, je pourrai examiner à nouveau la situation.
This forum is using the oauth2 basic plugin. Maybe there is a problem with that, might require a version roll back. Not sure yet. I did check the settings, all addresses were using https, so no obvious problem there.
Je rencontre un problème similaire :
Après avoir constaté que le logo et la grande icône étaient chargés via HTTP, ce qui provoquait un contenu mixte, l’activation de force_https a résolu ce problème. Cependant, la connexion n’était plus possible, entraînant une boucle de redirection. Après avoir désactivé cette option, la connexion fonctionne à nouveau.
Pourquoi cela se produit-il ?
Et pourquoi ces deux images uniquement sont-elles chargées via HTTP, alors que tous les autres actifs sont correctement chargés via HTTPS ?
Quelle est votre méthode de connexion ? Je suppose qu’il ne s’agit pas d’une connexion locale (nom d’utilisateur/mot de passe) ?
Y a-t-il un proxy ou un autre service devant votre installation ?
J’utilise SSO via une autre application web.
nginx est utilisé comme proxy inverse.
Comment nginx a-t-il été configuré ?
Nginx redirige toutes les requêtes HTTP vers HTTPS, il ne devrait donc pas être possible de charger du contenu via HTTP de toute façon.
Ma première idée serait de vérifier à nouveau votre configuration SSO pour voir où elle redirige les utilisateurs, ainsi que les origines qu’elle accepte. Assurez-vous que tout dans la configuration SSO utilise https://. Il est également possible que ce soit un problème lié à Nginx. Cela risque d’être difficile à déboguer ici avec plusieurs variables…
Je rencontre exactement le même problème que les personnes signalant ici et dans ce thread.
Le problème ne semble pas lié à l’implémentation de l’SSO ni au serveur web : dans mon cas, les requêtes HTTP sont redirigées vers HTTPS, qui sont ensuite transmises via le proxy inverse. L’SSO fonctionne parfaitement si je redirige l’utilisateur vers https://discourse.fqdn.top/session/sso_login?sso=PAYLOAD&sig=SIGNATURE et que force_https est à false. Cela montre que tant la partie SSO que le proxy fonctionnent parfaitement. Seulement lorsque je passe force_https à true, cela cesse de fonctionner. Lorsque j’ai une session préexistante, je peux passer force_https à true et utiliser Discourse sans aucun problème (ce qui renforce encore l’idée que le problème n’est pas lié au proxy inverse). Laisser force_https à false n’est pas une option car cela brise les logos et Chrome n’est pas content lorsque des ressources provenant de HTTP et HTTPS sont mélangées (il affiche une petite alerte dans la barre d’adresse indiquant que la page n’est pas sécurisée).
À quoi ressemble votre configuration nginx et avez-vous un en-tête X-Forwarded-Proto dans celle-ci ?
Merci beaucoup. Oui, cela a résolu le problème. Donc, c’était bien lié au proxy. Désolé d’avoir supposé le contraire, simplement parce que le contenu était chargé.
Pour être exhaustif, j’utilise Apache comme proxy inverse et non nginx. Voici les lignes de configuration pertinentes :
RequestHeader set X-Forwarded-Proto "https"
ProxyPass / http://[::1]:2045/ retry=10
ProxyPassReverse / http://[::1]:2045/
L’ajout de la première ligne a résolu le problème.
Salut,
désolé de remuer cela à nouveau, mais je n’arrive toujours pas à me débarrasser des avertissements de contenu mixte dans Firefox. Le plus drôle, c’est que ma configuration est à peu près la même… plus ou moins. Peut-être que quelqu’un pourra proposer des idées ou des améliorations. Je ne suis pas un grand expert des directives Apache, mais cela a du sens pour moi – du moins un peu.
Nous avons Discourse dans Docker derrière Apache via un proxy inverse, et nous gérons les certificats Let’s Encrypt avec ISPConfig, car nous avons de nombreux « domaines normaux » hébergés sur notre serveur.
Nous avons configuré le proxy inverse avec des directives Apache via ISPConfig. Notre configuration ressemble à ceci :
ProxyPreserveHost On
ProxyPass /.well-known/acme-challenge !
RequestHeader set X-Forwarded-Proto "https"
ProxyPass / unix:///var/discourse/shared/standalone/nginx.http.sock|http://localhost/
ProxyPassReverse / unix:///var/discourse/shared/standalone/nginx.http.sock|http://localhost/
RewriteEngine On
RewriteCond %{HTTPS} !on
RewriteRule (.*) https://sub.domain.de$1 [R,L]
Nous avons toujours des avertissements de contenu mixte dans Firefox. Ce que j’ai essayé, c’est d’activer l’option « forcer SSL » dans les paramètres. Dans un premier temps, nous n’avions plus accès à la connexion. Nous nous authentifions uniquement par nom d’utilisateur et mot de passe. J’ai donc essayé la solution mentionnée :
Eh bien, « forcer SSL » fonctionne désormais et la connexion est possible. Mais Firefox affiche toujours des avertissements de contenu mixte. La console indique :
et
sont livrés en HTTP… Nous avons aussi essayé de réimporter ces images de personnalisation via sub.domain.de/wizard, mais le problème persiste… Existe-t-il un moyen de… je ne sais pas, forcer le recalcul des images optimisées en HTTPS ? Y a-t-il un problème avec notre configuration de proxy inverse ?
Je serais très reconnaissant pour toute aide supplémentaire. C’est comme un océan de configurations possibles de proxy inverse avec le forçage de SSL via Let’s Encrypt (géré par) Apache (et non pas intégré dans la configuration de Discourse), donc je sens que je me noie. J’ai l’impression qu’il y a très peu de personnes utilisant Apache comme serveur avec un proxy inverse et cette configuration Let’s Encrypt. Ou alors, nous sommes simplement les seuls à mal le configurer.
Comme je l’ai dit, j’apprécierais vraiment toute indication. Merci d’avance !
Essayez SiteIconManager.ensure_optimized! depuis une console Rails.
Waouh, une réponse si rapide ! Merci beaucoup.
En attendant… je ne sais pas si cela a été déclenché par le temps écoulé, permettant à quelque chose de se produire. Mais ce que j’ai fait après avoir soumis mon premier message, c’est que j’ai à nouveau téléchargé ces deux images (favicon et icône Apple), sans utiliser l’assistant mais via les paramètres d’administration (personnalisation). Et juste à ce moment-là, alors que je voulais fermer l’onglet pour vérifier si la connexion et tout le reste fonctionnaient correctement… devinez quoi. Les erreurs de contenu mixte de Firefox ont disparu !
Waouh !
Eh bien, @RGJ, merci encore beaucoup. Je pense que cela réglerait aussi le problème de réaffichage des images optimisées. Pensez-vous que cela ait été déclenché entre-temps à cause d’un seuil de temps ou parce que j’ai re-téléchargé les images via le panneau d’administration et non l’assistant ?
Merci encore, surtout à @alphanoob1337 pour avoir enfin fait fonctionner tout cela !
Waouh, c’est plutôt désagréable pour un lundi de quitter son bureau avec un sentiment de satisfaction et de bonheur 
