I have looked at the related topics and also Google but I am not entirely sure what I need to do to fix this. Thanks!
 Since I don’t want to show this error message all over the time, I’ve enabled it on this one single old post only.
path allowed: /blog/.*
I’ve also enabled cors origin for these domains:
And also added
DISCOURSE_ENABLE_CORS: true in the ENV inside
app.yml so I am a bit stuck here…
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
Ubuntu 20.04.1 LTS
Full error message
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’).
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.
@simon Is this something that you can potentially help me with? Is this expected behavior or being fixed in a future release?
We’ve added this forum mostly to enable commenting on our site pages, and if this will not work then we need to look into other solutions.
There is an issue that I hadn’t noticed previously in this screenshot:
The Path Allowlist is set to
/blog/* instead of to
/blog/.* (note the addition of the dot character.)
Try editing the host entry to change the Path Allowlist to
If that doesn’t fix the issue, try
/.* Also try just leaving the setting empty.
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.
@simon I have tried all three:
(last one is empty) and none of those work.
The error I get in console looks more like a CORS issue than anything else.
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').
but I’m not sure how I might fix this. For testing, I have tried adding this to the app config already:
Essentially making it wide open but that doesn’t work either.
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.
@simon Yes username for topic creation is set to
system. I have also tried setting it to my own username and it gives the same error.
Of interest, today I have found the following:
curl -IXGET https://discuss.royaleapi.com
access-control-allow-headers: Content-Type, Cache-Control, X-Requested-With, X-CSRF-Token, Discourse-Present, User-Api-Key, User-Api-Client-Id, Authorization
date: Tue, 08 Dec 2020 23:52:26 GMT
last-modified: Tue, 01 Dec 2020 01:49:39 GMT
expires: Wed, 09 Dec 2020 23:52:26 GMT
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?
@simon I have resolved this issue.
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.
Please consider this issue closed.
Thanks so much for following up on this!
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.
Actually, @Falco shows the simply running
curl https://example.com/path/to -I
will show whether the method is implemented. This seems like a good way to check it.
Anyway, really appreciate the help from you both!
Oh sorry about that. I guess frameworks like Rails got me spoiled to the point I expect this to be a out of the box default for websites
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.:
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.
Ha, that’s clear now! Thank you.
I checked for the HEAD method, and my website correctly (200) responds to it.
I’m still struggling to embed a Discourse thread, but I will open a new thread if anything else fail.
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.