Bonjour à l’équipe du support !
Lorsque j’essaie d’intégrer le contenu à l’aide du snippet JS fourni, cela reste bloqué sur « Chargement de la discussion » et j’obtiens l’erreur suivante :
Invalid X-Frame-Options: « ALLOWALL » header from ...
Comment puis-je résoudre ce problème ?
Merci !
Cela peut être en retard, mais j’ai rencontré le même problème et j’aurais apprécié une réponse ici. Mon problème ne s’est manifesté qu’avec Firefox. Chrome fonctionnait sans problème. Je l’ai résolu en ajoutant le site qui intègre le contenu aux paramètres « origines CORS ». J’ai trouvé la piste ici.
Je viens de remarquer que nos sites rencontrent également ce problème, mais uniquement avec les nouveaux articles, et non avec les articles existants pour lesquels un sujet associé avait déjà été créé. L’en-tête Invalid X-Frame-Options semble être plutôt un avertissement de Firefox qu’une véritable erreur, car il apparaît systématiquement, même lorsque l’intégration réussit.
Un exemple fonctionnel (avec un sujet existant, lorsque l’intégration fonctionnait auparavant) :
Alors que cette page d’accueil :
reçoit finalement une réponse 400 Bad Request de notre instance Discourse..
J’ai parcouru ces forums et la documentation pour comprendre pourquoi cela pourrait se produire, mais je n’ai rien trouvé pour l’instant. Je pensais que cela pourrait être lié à l’inclusion du nom d’utilisateur Discourse dans la charge utile de l’intégration, mais cela se produit également pour le contenu créé par des utilisateurs correctement synchronisés (par exemple, Winter School on Agent-Based Modeling of Social-Ecological Systems).
Voici ce que j’ai vérifié :
DISCOURSE_ENABLE_CORS: trueest défini- Les hôtes CORS sont corrects dans les paramètres de Discourse avec https
- Les hôtes autorisés sont correctement configurés (l’intégration fonctionne également pour les publications Discourse déjà créées)
Y a-t-il d’autres éléments que je devrais envisager d’examiner ? La seule autre chose à laquelle je peux penser est que nous avons récemment intégré nos sites avec CloudFlare, il se peut donc qu’une configuration CloudFlare soit nécessaire pour que tout fonctionne correctement. Je suis toujours perplexe quant à la raison pour laquelle les sujets existants fonctionnent correctement…
Vous devriez essayer de désactiver Cloudflare temporairement et voir si cela aide. C’est assez facile à faire…
Bonne idée, je l’ai testé sur notre site de staging, mais malheureusement, cela n’a pas résolu le problème..
Sur Chrome, je vois des erreurs comme celle-ci :
Échec de l'exécution de 'postMessage' sur 'DOMWindow' : L'origine cible fournie ('https://test-discourse.comses.net') ne correspond pas à l'origine de la fenêtre destinataire ('https://test.comses.net').
(de https://test.comses.net/codebases/f0613922-9cb1-4656-a26c-af57f823fb69/releases/3.2.0/)
D’autres personnes ici ont semblé pouvoir résoudre ce problème en s’assurant que DiscourseEmbed.discourseEmbedUrl était identique à l’URL de référence, mais j’ai vérifié que cela était toujours correct.. J’ai fouillé dans les journaux Discourse (devrais-je regarder dans /var/discourse/shared/standalone/log/rails/production.log ?) mais je n’ai pas non plus vu d’erreurs là-dedans.. D’autres idées sur les endroits à explorer pour dépanner ce problème ?
Un exemple provenant des journaux Discourse :
Démarrage de GET "/embed/comments?embed_url=https%3A%2F%2Ftest.comses.net%2Fcodebases%2Ff0613922-9cb1-4656-a26c-af57f823fb69%2Freleases%2F3.2.0%2F" pour 72.201.57.141 le 2020-08-05 05:15:40 +0000
Traitement par EmbedController#comments en tant que HTML
Paramètres : {"embed_url"=>"https://test.comses.net/codebases/f0613922-9cb1-4656-a26c-af57f823fb69/releases/3.2.0/"}
Rendu de embed/loading.html.erb dans layouts/embed
Rendu de embed/loading.html.erb dans layouts/embed (Durée : 0,4 ms | Allocations : 134)
Terminé 200 OK en 91 ms (Vues : 1,8 ms | ActiveRecord : 0,0 ms | Allocations : 16308)
Démarrage de GET "/service-worker-c8000968830b6f6bd33f1e842dffdd569664119d449f93dc7d428d963a71635d.js" pour 72.201.57.141 le 2020-08-05 05:15:42 +0000
Traitement par StaticController#service_worker_asset en tant que */*
Rendu du modèle texte
Rendu du modèle texte (Durée : 0,0 ms | Allocations : 1)
Terminé 200 OK en 27 ms (Vues : 1,3 ms | ActiveRecord : 0,0 ms | Allocations : 6617)
Je rencontre le même problème. Vous pouvez le voir en direct, par exemple sur : Making sure you're not a bot! où, en bas, est intégrée la discussion depuis @mock/mock - Fedora Discussion. Notez que discussion.fedoraproject.org est une instance payante fournie en tant que service par Discourse.
Ce qui m’interroge, c’est que la discussion se charge parfois, mais pas toujours. Je parviens à reproduire le problème (presque systématiquement) en mode privé dans Firefox (version 80).
L’outil de développement affiche :
Un en-tête X-Frame-Options invalide a été détecté lors du chargement de « @mock/mock - Fedora Discussion » : « ALLOWALL » n’est pas une directive valide.
Et effectivement, la documentation X-Frame-Options header - HTTP | MDN ne reconnaît pas ALLOWALL comme une valeur valide.
Il semble que le sujet auquel vous avez fait référence à l’adresse https://discussion.fedoraproject.org/t/mock-mock/3107 se trouve dans une catégorie protégée : je n’y ai pas accès en tant qu’utilisateur anonyme. Tant que votre forum Discourse et votre site web partagent le même domaine racine, je m’attendrais à ce que les commentaires intégrés se chargent pour les utilisateurs connectés au forum, mais échouent pour ceux qui ne le sont pas. Cela correspond-il à ce que vous observez ?
Je m’attendrais à ce que les commentaires intégrés se chargent pour les utilisateurs connectés au forum, mais qu’ils échouent pour les utilisateurs non connectés. Cela correspond-il à ce que vous observez ?
Cela semble en effet être le cas. Je parviens à reproduire ce comportement à la fois dans Google Chrome et dans Firefox. Cependant, la discussion ne se charge pas en mode privé de l’un ou l’autre de ces navigateurs ; je ne sais pas si cela signifie quelque chose. Mais je suppose que cela nous oriente toujours vers la mise à jour de la catégorie, afin qu’elle puisse être visible par tous.
Merci. Après avoir modifié la catégorie et ajouté « tout le monde » dans l’onglet Sécurité avec les permissions « créer/répondre/voir », l’intégration fonctionne à nouveau.
Donc, après la dernière mise à jour de Discourse, toutes les pages intégrées signalent maintenant une erreur 
Un message d’erreur typique que nous voyons maintenant ressemble à ceci, ce qui semble indiquer que le navigateur effectue une suppression de l’en-tête Referer, ce qui fait échouer les vérifications de validation du code d’intégration de Discourse :
Referer : `https://www.comses.net/`
Le referer n'a soit pas été envoyé, soit ne correspond à aucun des hôtes suivants :
* www.comses.net/codebases/.*
Page exemple : Artificial Anasazi
Sur Chrome, même avec Privacy Badger et toutes les autres extensions désactivées, le message d’erreur relatif au referer apparaît toujours et est probablement dû à A new default Referrer-Policy for Chrome - strict-origin-when-cross-origin | Blog | Chrome for Developers MISE À JOUR cela fonctionne maintenant pour les sujets existants après avoir ajouté une politique de référent explicite au site d’origine (par exemple, https://www.comses.net), donc pour haproxy quelque chose comme : http-response set-header Referrer-Policy "no-referrer-when-downgrade"
Sur Firefox et Chrome, les pages avec des sujets existants fonctionnent, mais les pages qui tentent de créer un nouveau sujet échouent comme celle-ci : The Bronze Age Collapse model (BACO model).
J’ai modifié notre configuration haproxy pour définir les en-têtes de réponse pour Content-Security-Policy frame-ancestors, ce qui a corrigé une erreur X-Frame-Options ALLOWALL not recognized invalide dans Firefox, mais maintenant la requête expirée et aboutit finalement à une erreur 400 Bad Request de notre forum Discourse.
L’erreur semble être liée à postMessage :
Échec de l'exécution de 'postMessage' sur 'DOMWindow' : L'origine cible fournie ('https://forum.comses.net') ne correspond pas à l'origine de la fenêtre destinataire ('https://www.comses.net').
J’aurai plus de temps pour approfondir le sujet à la fin de ce mois, lorsque j’aurai un peu plus de temps libre, mais je voulais partager mes réflexions tant que c’est encore frais - j’espère que quelqu’un d’autre trouvera une solution de contournement d’ici là ! 
Il m’arrive la même chose. J’espère que quelqu’un ici pourra aider un peu avec cette erreur. Dans mon cas, j’ai un blog de test et un blog officiel… tous deux créés avec Webflow… sur le blog de test, tout fonctionne bien, mais cette erreur apparaît sur le blog en direct…
### Erreur d'intégration
Référent : `https://www.pynk.io/blog/what-to-invest-in-look-around-you`
Le référent n'a soit pas été envoyé, soit il ne correspond à aucun des hôtes suivants :
[espace vide ici]
Désolé pour la réponse tardive. Pouvez-vous essayer d’ajouter discourseReferrerPolicy: 'no-referrer-when-downgrade' à l’objet DiscourseEmbed défini dans l’extrait de code d’intégration ? Vous trouverez un exemple complet d’un extrait de code ajoutant cette propriété ici : Embed Discourse comments on another website via Javascript - #353.
Si vous essayez cela, faites-nous savoir si cela résout le problème pour vous.
Je pense que cela a été résolu ici : Embed Discourse comments on another website via Javascript - #365. Dans ce cas, le problème était l’absence du sous-domaine www sur l’enregistrement hôte intégrable de Discourse.
Édition : ce problème a maintenant été corrigé dans le code principal de Discourse. Il n’est plus nécessaire de définir la variable discourseReferrerPolicy sur 'no-referrer-when-downgrade'. Discourse définit désormais la politique de référent sur 'no-referrer-when-downgrade' par défaut. Pour plus de détails à ce sujet, voir https://meta.discourse.org/t/embedding-discourse-comments-via-javascript/31963#setting-the-referrer-policy.
L’ajout de discourseReferrerPolicy a résolu le problème — merci, @simon !! 
Cela pourrait poser des problèmes avec l’authentification unique (SSO). J’ai un current.discourse.example qui utilise sso.discourse.example comme hôte SSO. Lorsque vous êtes connecté, la liste des sujets s’affiche correctement. Mais lorsque vous êtes anonyme, elle ne s’affiche pas et l’erreur ci-dessus apparaît. L’URL /embed/topics?... affiche une page blanche.
Je pense — ou j’espère — que cela devrait être corrigé avec :
Content-Security-Policy: frame-ancestors https://current.discourse.example https://sso.discourse.example;