Are you sure the ?discuss=1 query param isn’t the cause of the issue?
Are there any security permissions on your blog category, or is it set to allow the group ‘everyone’ to Create / Reply / See?
What version of Discourse is your site on?
Also, what is the full error message that you see after the Failed to execute postMessage on DOMWindow text? I would expect it to be something like The target origin provided (<target_url>) does not match the recipient window's origin (<origin_url>).
I am certain that it has nothing to do the ?discuss=1 param. I had the same issue without it — it’s just that this is a live site and I don’t want to show a huge error block to our users. But since you’e asked, I have edited the site and instead enable the javascript embed on only one of our very old posts where there shouldn’t be any visitors. So no query string. (I’ve updated my first post to reflect this)
VM469 embed-application-9cef8308c816fc1d83137e63d6c556c6cc2b68fe2b6e5ce16cca6766ba2c0ae4.js:1 Failed to execute ‘postMessage’ on ‘DOMWindow’: The target origin provided (‘https://discuss.royaleapi.com’) does not match the recipient window’s origin (‘https://royaleapi.com’).
Blog Category
This is a public category - open to all. I’ve just made it so in fact there are no posts. I have made a new post right now to see if having a single item in the category is required.
Not sure if this could be relevant, but I do see some errors in the logs but I’m unsure what it is:
[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
also please let me know if any of this should be obfuscated. Since I’ve already posted the URL I figured that it’s no harm since these file locations appear to be standard to the setup.
Yeah my screenshot had the issue but i have since changed it to /blog/.* already since I realized that it’s likely using regex. However, the problem persists.
The error I get in console looks more like a CORS issue than anything else.
_embed-application-9cef8308c816fc1d83137e63d6c556c6cc2b68fe2b6e5ce16cca6766ba2c0ae4.js:7
Failed to execute 'postMessage' on 'DOMWindow':
The target origin provided ('https://discuss.royaleapi.com')
does not match the recipient window's origin ('https://royaleapi.com').
On the Discourse Embedding settings page, have you set the “Username for topic creation” setting? If it’s not set you’ll get the Failed to execute 'postMessage' on 'DOMWindow' error.
Could this be why? So it seems that the scripts themselves don’t have access-control-allow-origin headers even though the domain does. Should I try to use my own nginx config and not use what is built into the docker image?
In order to solve another issue Unable to generate preview for URLs - #4 by seeminglee — i have enabled HEAD requests on the site, and now all of the discussions showed up, and in turn, threads get automatically generated for my blog posts.
This is amazing — I can’t believe that I’ve gone down the rabbit hole of trying to determine if it’s a CORS-related issue when it’s related to HEAD requests. Perhaps this needs to be specified somewhere in the docs.
Possibly this should probably be added to the Troubleshooting section of Embed Discourse comments on another website via Javascript. I’m not sure how common it is to have HEAD requests disabled, but it’s a difficult issue to track down for sites where they have been disabled.
Well, if you got out of your way to block HEAD requests for URLs that respond to GET requests and violate the RFC some breakage is to be expected right?
tbh, I didn’t realize that there are services that depend it to exist. I wouldn’t have “disabled” the method if I knew that it is needed.
Also just to be clear: it’s not like I go out of my way to disable the method. I just didn’t write routes to support the HEAD method. So basically what I’ve done now is to add a function to respond to all HEAD requests to valid endpoints.
Yes, please: update the Troubleshooting section with this. I’m stuck with CORS/Frame security issues and I hope following @seeminglee’s steps could help. How do I enable HEAD requests?
@willywongi You might be confused about what my issue was, so let me explain what happened.
I’ve followed the steps but couldn’t get the comments to be embedded on the site.
Turns out my Discourse app (installed on a different domain) is not able to “verify” that my blog posts exist because my main site did not implement the HEAD method on those URLs.
After implementing handler for HEAD requests for those paths, the embed works.
To see if you have the same issue as I do, run curl against the URL that contain the blog post / wherever you want your comment embed to appear.
For example, if your URL is https://example.com/blog/awesome-post, go to terminal and run
curl https://example.com/blog/awesome-post -I
This will run a HEAD request to that URL and give you the result. If the status code is anything other than 200 (that’s the number on the first line of the response), e.g.:
HTTP/2 200
then the server doesn’t implement the HEAD method (OR it has issue responding to it).
If the response IS 200 then the embed issue has nothing to do with HEAD requests.
Ran into this and the problem turned out to be I changed the way “Username for topic creation” was called and forgot to update it in the Embedding page, guess it tried to create the topic and wouldn’t find the username. Once updated it in the embedding settings page the error went away.
