Contenu mixte : La page à « <URL> » a été chargée via HTTPS, mais a demandé une police non sécurisée « <URL> ». Cette requête a été bloquée ; le contenu doit être servi via HTTPS.
Et 40 requêtes de polices du gem discourse-fonts. Il s’agit d’une nouvelle installation où Postgres et Redis sont exécutés sur un serveur séparé à l’intérieur du réseau local et la connexion est « socketée » mais servie à l’extérieur via HTTPS, bien sûr. Il existe des fils similairesfils mais aucune réponse claire pour moi. La vérification du CSS pointe vers wizard.scss (source-mappé). Des indices ?
Très probablement non. Où dois-je le définir ? Et pourquoi serait-il nécessaire en premier lieu au lieu que la requête CSS d’actifs statiques soit en https ou références relatives ?
FWIW - sur le serveur web externe, j’ai la configuration 301 typique
Eh bien, moi non plus. Je n’ai rien modifié. Juste le launcher build app habituel. Ces URL semblent se trouver dans le CSS traité, que je n’ai évidemment pas touché (ni le scss) de quelque manière que ce soit. Je n’ai rien trouvé de lié à https dans le fichier app.yml non plus, donc… je ne sais pas. Le force_https semble contourner le problème.
Cela dépend de la façon dont nous définissons « nécessaire ». Actuellement, il pourrait être nécessaire de contourner le problème réel, à savoir que les fichiers CSS compilés référencent des ressources statiques explicitement à l’aide du schéma http. Mais à mon avis, cela ne devrait pas être nécessaire à long terme.
Nécessaire dans le sens où c’est le but de FORCE_HTTPS - c’est ainsi que vous indiquez à Discourse qu’il est servi de manière sécurisée et que vous réécrivez les liens en conséquence.
Dans ce cas, si vous activez force_https, vous vous retrouverez avec une erreur d’URL de toutes les ressources R_SSL_PROTOCOL_ERROR si le domaine demandé n’a pas de certificat installé. Ensuite, pour éviter cela, vous installez un certificat pour résoudre le problème de protocole SSL.
Si vous installez Discourse avec le modèle ci-dessus décommenté, l’URL des ressources du site doit être HTTPS, ainsi que le protocole de l’URL de base de votre site. De plus, force https est invisible dans l’interface d’administration.
Comme mentionné dans le post original, dans mon cas, le certificat et tout le reste est correct et valide, mais toutes les connexions vers l’extérieur sont gérées par un reverse-proxy (nginx, évidemment ;-)), tandis que la connexion à Discourse se fait via un socket Unix. Cela signifie que j’ai templates/web.socketed.template.yml plutôt que ceux que vous mentionnez. Néanmoins, cela ne devrait pas obliger les URL statiques à avoir un schéma http: codé en dur.
