Rien dans les journaux d’erreurs, d’après ce que je peux voir.
Il a également échoué pour un iframe intégré différent provenant d’un domaine source différent que j’ai autorisé.
Exactement le même type d’iframe intégré provenant du même domaine source a fonctionné la dernière fois que j’ai essayé, il y a peut-être 6 mois ou un an. Maintenant, je suis sur Discourse v3.3.1 +5 (branche stable).
Sur la dernière version de la branche tests-passed, les iframe s’intègrent sans problème. Notez que les attributs style et title que vous avez définis seront supprimés par Discourse. Vous pouvez cependant définir les attributs width et height. Par exemple :
Failed to load resource: net::ERR_CONNECTION_REFUSED beacon.min.js:1
Mais cela semble être une liste noire DNS que j’utilise. Lorsque je me connecte via un VPN, il n’y a pas d’erreurs. Et cela semble plus qu’une coïncidence qu’un autre utilisateur avec un ordinateur et un réseau complètement différents m’ait initialement signalé ce même problème.
OK Firefox m’affiche un autre message de console :
Partitioned cookie or storage access was provided to “https://www.tickcounter.com/widget/countdown/4471981” because it is loaded in the third-party context and dynamic state partitioning is enabled. [En savoir plus]
Je devrais aussi mentionner que j’ai collé le code iframe dans un fichier HTML statique squelette et que je l’ai ouvert dans le navigateur et qu’il a correctement chargé l’iframe.
ok cet iframe fonctionnait pour vous… Êtes-vous sur Cloudflare par hasard ? si oui, jetez un œil et voyez si la désactivation de la « speed brain » change quelque chose ? (si elle est activée) Je sais que c’est une chose relativement nouvelle.
[citation=“Lilly, post:8, topic:327852”]
quelque chose le bloque sur votre forum
[/citation]
Hmm, oui, c’est ce que ça semble être. Mais Discourse ne devrait-il pas avoir une erreur dans /logs/ ?
Je n’exécute rien qui, selon moi, pourrait bloquer cela sur le serveur. J’utilisais le DNS du fournisseur d’hébergement dans mon /etc/resolv.conf, et j’ai essayé de le remplacer par 8.8.8.8 sans que cela ne change rien à ce problème.
seulement si cela cause une erreur. quelque chose pourrait le bloquer pour des raisons de bon fonctionnement. ma supposition est d’essayer de déterminer si/ce qui a changé au moment où cela a cessé de fonctionner. je me demande si un changement de politique de sécurité de contenu aurait pu l’affecter.
C’est un service DNS qui bloque les domaines ayant une mauvaise réputation. Mais ce n’est pas le problème car 1) lorsque je me connecte via un VPN, il utilise un DNS différent et ce problème persiste, et 2) l’utilisateur qui m’a signalé ce problème utilise une configuration complètement différente, 3) la configuration DNS est uniquement pour mon réseau local et non sur le serveur Discourse qui ne parvient pas à générer le bon HTML côté serveur, et 4) ce fichier HTML charge correctement l’iframe :
Oh wow, c’était ça, il manquait le / final.
Merci beaucoup !
Quelque chose a changé dans Discourse, car j’avais ajouté https://www.tickcounter.com la dernière fois que j’ai essayé et à ce moment-là, cela fonctionnait. À mon avis, soit la logique regexp qu’il utilise, soit la description du paramètre doit être ajustée, car il est indiqué :
Une liste de préfixes de domaines src d’iframe que Discourse peut autoriser en toute sécurité dans les publications
Quand je pense à un “préfixe de domaine”, je pense à un nom de domaine et/ou à un sous-domaine, qui n’incluent pas de /. Ou s’il est censé utiliser une logique plus précise pour les URL src d’iframe complexes, il devrait indiquer quelque chose comme :
Une liste de préfixes d’URL src d’iframe que Discourse peut autoriser en toute sécurité dans les publications
Les liens ajoutés il y a plus de 2 mois (avant que le correctif de sécurité ne soit fusionné) sont le problème, à l’époque vous ne receviez pas de message d’erreur et même les liens par défaut ne contenaient pas de troisième ‘/’.
C’est au moins le deuxième sujet de support à cause de cela
hmmm. Cela semble fonctionner comme prévu pour moi aussi.
