J’ai consulté les sujets connexes et effectué des recherches sur Google, mais je ne suis pas tout à fait certain de la démarche à suivre pour résoudre ce problème. Merci !
[edit] Comme je ne souhaite pas afficher ce message d’erreur partout, je ne l’ai activé que sur cet unique ancien post.
Êtes-vous sûr que le paramètre de requête ?discuss=1 n’est pas la cause du problème ?
Y a-t-il des autorisations de sécurité sur votre catégorie de blog, ou est-elle configurée pour permettre au groupe « tout le monde » de Créer / Répondre / Voir ?
Quelle version de Discourse votre site utilise-t-il ?
En outre, quel est le message d’erreur complet que vous voyez après le texte Failed to execute postMessage on DOMWindow ? Je m’attendrais à ce que ce soit quelque chose comme The target origin provided (<target_url>) does not match the recipient window's origin (<origin_url>).
Je suis certain que cela n’a rien à voir avec le paramètre ?discuss=1. J’avais rencontré le même problème sans celui-ci — c’est juste que c’est un site en direct et je ne veux pas afficher un gros bloc d’erreur à nos utilisateurs. Mais puisque vous l’avez demandé, j’ai modifié le site pour activer l’intégration JavaScript uniquement sur l’un de nos très anciens articles où il ne devrait y avoir aucun visiteur. Donc aucune chaîne de requête. (J’ai mis à jour mon premier message pour refléter cela)
VM469 embed-application-9cef8308c816fc1d83137e63d6c556c6cc2b68fe2b6e5ce16cca6766ba2c0ae4.js:1 Échec de l’exécution de « postMessage » sur « DOMWindow » : l’origine cible fournie (« https://discuss.royaleapi.com ») ne correspond pas à l’origine de la fenêtre destinataire (« https://royaleapi.com »).
Catégorie du blog
Il s’agit d’une catégorie publique, ouverte à tous. Je l’ai simplement configurée ainsi ; en fait, il n’y a aucun article. Je viens de créer un nouvel article pour vérifier si la présence d’un seul élément dans la catégorie est requise.
Je ne suis pas sûr que cela puisse être pertinent, mais je vois quelques erreurs dans les journaux, sans savoir exactement de quoi il s’agit :
[Ven 06 Nov 2020 16:47:14 UTC] Les domaines n'ont pas été modifiés.
[Ven 06 Nov 2020 16:47:14 UTC] Ignoré, le prochain moment de renouvellement est : Lun 04 Jan 2021 08:07:59 UTC
[Ven 06 Nov 2020 16:47:14 UTC] Ajoutez '--force' pour forcer le renouvellement.
[Ven 06 Nov 2020 16:47:14 UTC] Installation de la clé vers :/shared/ssl/discuss.royaleapi.com_ecc.key
[Ven 06 Nov 2020 16:47:14 UTC] Installation de la chaîne complète vers :/shared/ssl/discuss.royaleapi.com_ecc.cer
[Ven 06 Nov 2020 16:47:14 UTC] Exécution de la commande de rechargement : sv reload nginx
warning: nginx: impossible d'ouvrir supervise/ok : le fichier n'existe pas
[Ven 06 Nov 2020 16:47:14 UTC] Erreur de rechargement pour :
Démarrage de runsvdir, PID est 663
ok: run: redis: (pid 677) 0s
chgrp: groupe invalide : 'syslog'
ok: run: postgres: (pid 675) 0s
rsyslogd: imklog : impossible d'ouvrir le journal du noyau (/proc/kmsg) : Opération non autorisée.
rsyslogd : échec de l'activation du module imklog [v8.1901.0 essayez https://www.rsyslog.com/e/2145 ]
supervisor pid: 671 unicorn pid: 702
Veuillez également me faire savoir si l’un de ces éléments doit être obscurci. Puisque j’ai déjà publié l’URL, je suppose qu’il n’y a pas de mal, car ces emplacements de fichiers semblent standards pour cette configuration.
@simon Est-ce quelque chose avec quoi tu pourrais potentiellement m’aider ? Ce comportement est-il attendu ou sera-t-il corrigé dans une prochaine version ?
Nous avons ajouté ce forum principalement pour permettre les commentaires sur les pages de notre site, et si cela ne fonctionne pas, nous devrons explorer d’autres solutions.
Oui, ma capture d’écran montrait le problème, mais je l’ai depuis modifié en /blog/.* car j’ai réalisé qu’il utilisait probablement une expression régulière. Cependant, le problème persiste.
(celui de la fin est vide) et aucun ne fonctionne.
L’erreur que je reçois dans la console ressemble davantage à un problème CORS qu’à autre chose.
_embed-application-9cef8308c816fc1d83137e63d6c556c6cc2b68fe2b6e5ce16cca6766ba2c0ae4.js:7
Échec de l'exécution de 'postMessage' sur 'DOMWindow' :
l'origine cible fournie ('https://discuss.royaleapi.com')
n'est pas conforme à l'origine de la fenêtre destinataire ('https://royaleapi.com').
Sur la page des paramètres d’intégration de Discourse, avez-vous configuré le paramètre « Nom d’utilisateur pour la création de sujets » ? S’il n’est pas configuré, vous rencontrerez l’erreur Failed to execute 'postMessage' on 'DOMWindow'.
@simon Oui, le nom d’utilisateur pour la création de sujets est défini sur system. J’ai également essayé de le définir sur mon propre nom d’utilisateur, mais cela génère la même erreur.
Cela pourrait-il en être la cause ? Il semble que les scripts eux-mêmes ne possèdent pas d’en-têtes access-control-allow-origin, même si le domaine en dispose. Devrais-je essayer d’utiliser ma propre configuration nginx au lieu de celle intégrée à l’image Docker ?
Pour résoudre un autre problème Unable to generate preview for URLs - #4 by seeminglee, j’ai activé les requêtes HEAD sur le site. Désormais, toutes les discussions s’affichent, et par conséquent, des fils de discussion sont automatiquement générés pour mes articles de blog.
C’est incroyable — je n’arrive pas à croire que je me sois lancé dans une recherche pour déterminer s’il s’agissait d’un problème lié au CORS alors qu’il était en fait lié aux requêtes HEAD. Peut-être faudrait-il le préciser quelque part dans la documentation.
Merci beaucoup d’avoir fait un suivi sur ce sujet !
Il faudrait probablement ajouter cela à la section Dépannage de Embed Discourse comments on another website via Javascript. Je ne sais pas à quel point il est courant d’avoir les requêtes HEAD désactivées, mais c’est un problème difficile à identifier pour les sites où elles sont désactivées.
Eh bien, si vous avez fait l’effort de bloquer les requêtes HEAD pour les URL qui répondent aux requêtes GET et qui violent la RFC, il est normal de s’attendre à des dysfonctionnements, non ?
Pour être honnête, je ne savais pas qu’il existait des services qui en dépendent. Je n’aurais pas « désactivé » la méthode si j’avais su qu’elle était nécessaire.
Pour être tout à fait clair : ce n’est pas que je fasse un effort particulier pour désactiver la méthode. Je n’ai simplement pas écrit de routes pour prendre en charge la méthode HEAD. Donc, ce que j’ai fait maintenant, c’est ajouter une fonction pour répondre à toutes les requêtes HEAD vers des points de terminaison valides.
Oh, désolé pour ça. Je suppose que des frameworks comme Rails m’ont gâté au point où j’attends que ce soit une fonctionnalité par défaut intégrée pour les sites web
Oui, s’il vous plaît : mettez à jour la section Dépannage avec cela. Je suis bloqué avec des problèmes de sécurité CORS/Frame et j’espère que suivre les étapes de @seeminglee pourrait aider. Comment activer les requêtes HEAD ?
@willywongi Il est possible que vous ayez mal compris mon problème, alors laissez-moi vous expliquer ce qui s’est passé.
J’ai suivi les étapes, mais je n’ai pas réussi à intégrer les commentaires sur le site.
Il s’avère que mon application Discourse (installée sur un autre domaine) n’a pas pu « vérifier » l’existence de mes articles de blog, car mon site principal n’implémentait pas la méthode HEAD pour ces URL.
Après avoir implémenté un gestionnaire pour les requêtes HEAD sur ces chemins, l’intégration fonctionne.
Pour vérifier si vous rencontrez le même problème que moi, exécutez curl contre l’URL contenant l’article de blog ou l’endroit où vous souhaitez que l’intégration des commentaires apparaisse.
Par exemple, si votre URL est https://example.com/blog/awesome-post, ouvrez un terminal et exécutez :
curl https://example.com/blog/awesome-post -I
Cela effectuera une requête HEAD sur cette URL et vous affichera le résultat. Si le code de statut est autre que 200 (c’est le chiffre sur la première ligne de la réponse), par exemple :
HTTP/2 200
alors le serveur n’implémente pas la méthode HEAD (OU il rencontre un problème pour y répondre).
Si la réponse est bien 200, alors le problème d’intégration n’a rien à voir avec les requêtes HEAD.
J’ai rencontré ceci et le problème s’est avéré être que j’avais changé la façon dont le « Nom d’utilisateur pour la création de sujet » était appelé et j’avais oublié de le mettre à jour sur la page d’intégration. Je suppose qu’il a essayé de créer le sujet et n’a pas trouvé le nom d’utilisateur. Une fois mis à jour sur la page des paramètres d’intégration, l’erreur a disparu.
