Ich habe die entsprechenden Themen durchsucht und auch bei Google gesucht, bin mir aber nicht ganz sicher, was ich tun muss, um das Problem zu beheben. Danke!
[Bearbeiten] Da ich diese Fehlermeldung nicht ständig anzeigen lassen möchte, habe ich sie nur für diesen einen alten Beitrag aktiviert.
Ich bin mir sicher, dass dies nichts mit dem Parameter ?discuss=1 zu tun hat. Ich hatte das gleiche Problem ohne ihn – es ist nur so, dass dies eine Live-Website ist und ich unseren Nutzern keinen riesigen Fehlerblock anzeigen möchte. Aber da Sie danach gefragt haben, habe ich die Website bearbeitet und stattdessen die JavaScript-Einbettung nur auf einen unserer sehr alten Beiträge aktiviert, wo ohnehin keine Besucher zu erwarten sind. Also keine Abfragezeichenfolge. (Ich habe meinen ersten Beitrag entsprechend aktualisiert.)
VM469 embed-application-9cef8308c816fc1d83137e63d6c556c6cc2b68fe2b6e5ce16cca6766ba2c0ae4.js:1 Ausführung von „postMessage“ auf „DOMWindow“ fehlgeschlagen: Der angegebene Zielursprung (‘https://discuss.royaleapi.com’) stimmt nicht mit dem Ursprung des empfangenden Fensters (‘https://royaleapi.com’) überein.
Blog-Kategorie
Dies ist eine öffentliche Kategorie, die für alle offen ist. Ich habe sie tatsächlich so eingerichtet, dass keine Beiträge vorhanden sind. Ich habe gerade einen neuen Beitrag erstellt, um zu prüfen, ob ein einzelnes Element in der Kategorie erforderlich ist.
Ich bin mir nicht sicher, ob das relevant sein könnte, aber ich sehe einige Fehler in den Logs, weiß aber nicht genau, worum es sich handelt:
[Fri 06 Nov 2020 04:47:14 PM UTC] Domains not changed.
[Fri 06 Nov 2020 04:47:14 PM UTC] Skip, Next renewal time is: Mon 04 Jan 2021 08:07:59 AM UTC
[Fri 06 Nov 2020 04:47:14 PM UTC] Add '--force' to force to renew.
[Fri 06 Nov 2020 04:47:14 PM UTC] Installing key to:/shared/ssl/discuss.royaleapi.com_ecc.key
[Fri 06 Nov 2020 04:47:14 PM UTC] Installing full chain to:/shared/ssl/discuss.royaleapi.com_ecc.cer
[Fri 06 Nov 2020 04:47:14 PM UTC] Run reload cmd: sv reload nginx
warning: nginx: unable to open supervise/ok: file does not exist
[Fri 06 Nov 2020 04:47:14 PM UTC] Reload error for :
Started runsvdir, PID is 663
ok: run: redis: (pid 677) 0s
chgrp: invalid group: 'syslog'
ok: run: postgres: (pid 675) 0s
rsyslogd: imklog: cannot open kernel log (/proc/kmsg): Operation not permitted.
rsyslogd: activation of module imklog failed [v8.1901.0 try https://www.rsyslog.com/e/2145 ]
supervisor pid: 671 unicorn pid: 702
Bitte lass mich auch wissen, ob einer dieser Einträge verschleiert werden sollte. Da ich die URL bereits veröffentlicht habe, dachte ich, es schadet nicht, da diese Dateipfade für die Einrichtung standardmäßig zu sein scheinen.
@simon Kannst du mir dabei eventuell helfen? Ist dies ein erwartetes Verhalten oder wird es in einem zukünftigen Release behoben?
Wir haben dieses Forum hauptsächlich hinzugefügt, um Kommentare auf unseren Seiten zu ermöglichen. Falls dies nicht funktioniert, müssen wir nach anderen Lösungen suchen.
Ja, mein Screenshot zeigte das Problem, aber ich habe es inzwischen bereits auf /blog/.* geändert, da mir klar wurde, dass es wahrscheinlich Regex verwendet. Das Problem besteht jedoch weiterhin.
(die letzte ist leer), und keine davon funktioniert.
Der Fehler in der Konsole sieht eher nach einem CORS-Problem aus als nach irgendetwas anderem.
_embed-application-9cef8308c816fc1d83137e63d6c556c6cc2b68fe2b6e5ce16cca6766ba2c0ae4.js:7
Ausführung von 'postMessage' auf 'DOMWindow' fehlgeschlagen:
Der bereitgestellte Ziel-Ursprung ('https://discuss.royaleapi.com')
stimmt nicht mit dem Ursprung des empfangenden Fensters ('https://royaleapi.com') überein.
@simon Ja, der Benutzername für die Erstellung von Themen ist auf system gesetzt. Ich habe es auch versucht, ihn auf meinen eigenen Benutzernamen zu setzen, aber es tritt derselbe Fehler auf.
Interessant ist, dass ich heute Folgendes festgestellt habe:
Könnte das der Grund sein? Es scheint also, dass die Skripte selbst keine access-control-allow-origin-Header haben, obwohl die Domain dies tut. Sollte ich versuchen, meine eigene nginx-Konfiguration zu verwenden und nicht die, die im Docker-Image integriert ist?
Um ein anderes Problem zu lösen Unable to generate preview for URLs - #4 by seeminglee, habe ich HEAD-Anfragen auf der Site aktiviert. Dadurch wurden nun alle Diskussionen angezeigt, und Folglich wurden automatisch Threads für meine Blogbeiträge erstellt.
Das ist fantastisch – ich kann kaum glauben, dass ich mich auf die Suche nach einem CORS-bezogenen Problem begeben habe, obwohl es eigentlich mit HEAD-Anfragen zusammenhängt. Vielleicht sollte dies irgendwo in der Dokumentation erwähnt werden.
Bitte betrachten Sie dieses Problem als abgeschlossen.
Nun, wenn Sie extra den Weg gegangen sind, um HEAD-Anfragen für URLs zu blockieren, die auf GET-Anfragen antworten und die RFC verletzen, sind dann nicht einige Störungen zu erwarten?
ehrlich gesagt, habe ich nicht gewusst, dass es Dienste gibt, die darauf angewiesen sind. Ich hätte die Methode nicht „deaktiviert“, wenn ich gewusst hätte, dass sie benötigt wird.
Zur Klarstellung: Es ist nicht so, dass ich extra darum bemüht bin, die Methode zu deaktivieren. Ich habe einfach keine Routen geschrieben, die die HEAD-Methode unterstützen. Im Grunde habe ich jetzt eine Funktion hinzugefügt, um auf alle HEAD-Anfragen an gültige Endpunkte zu antworten.
Oh, das tut mir leid. Ich denke, Frameworks wie Rails haben mich so verwöhnt, dass ich erwarte, dass dies standardmäßig für Websites bereitgestellt wird
@willywongi Du bist vielleicht verwirrt darüber, was mein Problem war, also lass mich erklären, was passiert ist.
Ich habe die Schritte befolgt, konnte aber keine Kommentare auf der Website einbetten.
Es stellte sich heraus, dass meine Discourse-App (die auf einer anderen Domain installiert ist) nicht „verifizieren“ kann, dass meine Blogbeiträge existieren, weil meine Hauptwebsite die HEAD-Methode für diese URLs nicht implementiert hat.
Nachdem ich einen Handler für HEAD-Anfragen für diese Pfade implementiert habe, funktioniert die Einbettung.
Um zu prüfen, ob du das gleiche Problem hast wie ich, führe curl gegen die URL aus, die den Blogbeitrag enthält bzw. wo du die Kommentareinbettung anzeigen möchtest.
Wenn deine URL beispielsweise https://example.com/blog/awesome-post lautet, öffne das Terminal und führe folgenden Befehl aus:
curl https://example.com/blog/awesome-post -I
Dadurch wird eine HEAD-Anfrage an diese URL gesendet und das Ergebnis ausgegeben. Wenn der Statuscode etwas anderes als 200 ist (das ist die Zahl in der ersten Zeile der Antwort), z. B.:
HTTP/2 200
dann implementiert der Server die HEAD-Methode nicht (oder es gibt ein Problem bei der Antwort darauf).
Wenn die Antwort 200 ist, hat das Problem mit der Einbettung nichts mit HEAD-Anfragen zu tun.
Ich bin auf dieses Problem gestoßen und es stellte sich heraus, dass ich die Art und Weise geändert hatte, wie „Benutzername für die Themen-Erstellung“ aufgerufen wurde, und vergessen hatte, ihn auf der Einbettungsseite zu aktualisieren. Ich vermute, es versuchte, das Thema zu erstellen, fand aber den Benutzernamen nicht. Sobald ich ihn auf der Einstellungsseite für die Einbettung aktualisiert hatte, verschwand der Fehler.
