JavaScript embed won’t display embed, console log shows: Failed to execute postMessage on DOMWindow…

support
#1

Hi, I have this same exact error when trying to integrate javascript embedding on our site.

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!

[edit] 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.

Embed settings:

Screen Shot 2020-11-06 at 5.56.06 PM
Screen Shot 2020-11-06 at 5.56.06 PM1968×544 49.5 KB

Settings tried:

host: royaleapi.com
path allowed: /blog/.*

host: royaleapi.com
path allowed:

I’ve also enabled cors origin for these domains:

  • https://royaleapi.com
  • https://cdn.royaleapi.com

And also added DISCOURSE_ENABLE_CORS: true in the ENV inside app.yml so I am a bit stuck here…

Embedding Discourse Comments via Javascript
#2

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>).

#3

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)

https://royaleapi.com/blog/season3

https://royaleapi.com/blog/season3

Discourse Version

2.6.0.beta5

OS Version

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’).

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.

Screenshot: Desktop

Screen Shot 2020-11-07 at 4.53.12 AM
Screen Shot 2020-11-07 at 4.53.12 AM1186×162 15.1 KB

Screenshot: Mobile

IMG_5878
IMG_5878750×396 54 KB

1 Like
#5

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.

#6

@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.

Thanks!

#7

There is an issue that I hadn’t noticed previously in this screenshot:

image

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 /blog/.*

If that doesn’t fix the issue, try /.* Also try just leaving the setting empty.

1 Like
#8

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.

#9

@simon I have tried all three:

/blog/.*
/.*

(last one is empty) and none of those work.

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').

Screen Shot 2020-12-01 at 9.05.08 AM
Screen Shot 2020-12-01 at 9.05.08 AM1108×322 62.7 KB

but I’m not sure how I might fix this. For testing, I have tried adding this to the app config already:

  DISCOURSE_ENABLE_CORS: true
  DISCOURSE_CORS_ORIGIN: '*'

Essentially making it wide open but that doesn’t work either.

#10

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.

1 Like
#11

@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-origin: *
access-control-allow-headers: Content-Type, Cache-Control, X-Requested-With, 	X-CSRF-Token, Discourse-Present, User-Api-Key, User-Api-Client-Id, Authorization
access-control-allow-credentials: true
[truncated]

However:

curl -IXGET https://discuss.royaleapi.com/javascripts/embed.js

HTTP/2 200
server: nginx
date: Tue, 08 Dec 2020 23:52:26 GMT
content-type: application/javascript
content-length: 2404
last-modified: Tue, 01 Dec 2020 01:49:39 GMT
vary: Accept-Encoding
expires: Wed, 09 Dec 2020 23:52:26 GMT
cache-control: max-age=86400
cache-control: public,immutable
accept-ranges: bytes

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?

#12

@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.

1 Like
#13

Thanks so much for following up on this!

Possibly this should probably be added to the Troubleshooting section of Embedding Discourse Comments 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.

#14

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?

#15

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.

2 Likes
#16

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!

2 Likes
#17

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 :sweat_smile:

1 Like
#18

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?

#19

@willywongi You might be confused about what my issue was, so let me explain what happened.

  1. I’ve followed the steps but couldn’t get the comments to be embedded on the site.
  2. 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.
  3. 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.

#20

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.