Hi Support team!
When I try embedding with the provided js snippet, it will stuck at “Loading Discussion” and I get the following error:
Invalid X-Frame-Options: “ALLOWALL” header from ...
How can I resolve this issue?
Thanks!
This might be late, by I ran into the same problem, and would have appreciated an answer here. My problem only appeared when using Firefox. Chrome worked, no probem. I fixed it by adding the site embedding the content to the “cors origins” setting. Got the lead here.
2 Likes
I just noticed that our sites are running into this issue as well, but only with new posts, not existing posts that already had a companion topic created for them. The Invalid X-Frame-Options header appears to be a firefox warning more than an actual error as it always shows up, even if the embedding succeeds.
A working example (with an existing topic when embedding used to work)
https://www.comses.net/codebases/5278/releases/1.0.0/
Whereas this landing page:
https://www.comses.net/codebases/8f1d300e-6333-4b36-820f-c414016ea395/releases/1.0.0/
eventually receives a 400 bad request response from our Discourse instance…
I’ve been scouring these forums and the documentation for why this might be occurring but haven’t found anything yet… I thought it might be related to us including the discourse username in the embed payload but this also occurs for content created by users that are properly synced (e.g., Winter School on Agent-Based Modeling of Social-Ecological Systems)
Things I’ve checked:
-
DISCOURSE_ENABLE_CORS: trueis set - cors hosts are correct in the discourse settings with https
- allowed hosts are set properly (also the embedding works for already created discourse posts)
any other things I should consider looking into? The only other thing I can think of is that we recently integrated our sites with CloudFlare so perhaps there is some cloudflare config that needs to happen to make things work properly. I’m still puzzled as to why existing topics work properly though…
You should try disabling cloudflare temporarily and see if that helps. Easy enough to do…
1 Like
Good call, I tried it out on our staging site but unfortunately it didn’t fix things…
On Chrome I see errors like the following:
Failed to execute 'postMessage' on 'DOMWindow': The target origin provided ('https://test-discourse.comses.net') does not match the recipient window's origin ('https://test.comses.net').
(from The Garbage Can Model of Organizational Choice)
Other people here seemed to be able to fix this by ensuring that the DiscourseEmbed.discourseEmbedUrl was the same as the referring URL but I verified that it was still correct… I poked around the Discourse logs (should I be looking at /var/discourse/shared/standalone/log/rails/production.log ?) but didn’t see any errors there either… any other ideas on places to look to troubleshoot this?
An example from the Discourse logs:
Started GET "/embed/comments?embed_url=https%3A%2F%2Ftest.comses.net%2Fcodebases%2Ff0613922-9cb1-4656-a26c-af57f823fb69%2Freleases%2F3.2.0%2F" for 72.201.57.141 at 2020-08-05 05:15:40 +0000
Processing by EmbedController#comments as HTML
Parameters: {"embed_url"=>"https://test.comses.net/codebases/f0613922-9cb1-4656-a26c-af57f823fb69/releases/3.2.0/"}
Rendering embed/loading.html.erb within layouts/embed
Rendered embed/loading.html.erb within layouts/embed (Duration: 0.4ms | Allocations: 134)
Completed 200 OK in 91ms (Views: 1.8ms | ActiveRecord: 0.0ms | Allocations: 16308)
Started GET "/service-worker-c8000968830b6f6bd33f1e842dffdd569664119d449f93dc7d428d963a71635d.js" for 72.201.57.141 at 2020-08-05 05:15:42 +0000
Processing by StaticController#service_worker_asset as */*
Rendering text template
Rendered text template (Duration: 0.0ms | Allocations: 1)
Completed 200 OK in 27ms (Views: 1.3ms | ActiveRecord: 0.0ms | Allocations: 6617)
I have the same issue. You can see that live on e.g.: @mock/mock Copr where at the bottom is embedded discussion from https://discussion.fedoraproject.org/t/mock-mock/3107 Note that discussion.fedoraproject.org is paid instance and provided as a service by Discourse.
What puzzle me, is that the discussion sometime loads. Sometimes not. I am able to reproduce it (nearly alwasy) in Private Mode in Firefox (ver. 80).
The developer tool shows:
Invalid X-Frame-Options header was found when loading “https://discussion.fedoraproject.org/embed/comments?embed_url=https%3A%2F%2Fcopr.fedorainfracloud.org%2Fcoprs%2Fg%2Fmock%2Fmock%2F”: “ALLOWALL” is not a valid directive.
And indeed, the documentation X-Frame-Options - HTTP | MDN does not recognize ALLOWALL as an value.
It looks like the topic that you linked to at https://discussion.fedoraproject.org/t/mock-mock/3107 is in a protected category - I am not able to access it as an anonymous user. As long as your Discourse forum and your website share the same root domain, I would expect embedded comments to load for users who are logged into the forum, but fail to load for users who are not logged into the forum. Does this sound like it matches what you are seeing?
1 Like
I would expect embedded comments to load for users who are logged into the forum, but fail to load for users who are not logged into the forum. Does this sound like it matches what you are seeing?
This indeed seems to be the case. I am able to reproduce this behavior in both google chrome and firefox. The discussion doesn’t load in a private mode of either of those browsers though, I don’t know if it means anything. But I guess it still points us to updating the category, so it can be seen by everyone.
1 Like
Thank you. After editing the category and in Security tab adding “everyone” can “create/reply/see” the embedding works again.
2 Likes
So after the latest Discourse update all embedded pages now report an error 
A typical error message we see now goes something like this, which seems to indicate that the browser is doing some referer stripping and causing the Discourse embed code to fail its validation checks:
Referer: `https://www.comses.net/`
The referer was either not sent, or did not match any of the following hosts:
* www.comses.net/codebases/.*
Example page: Artificial Anasazi
On Chrome, even with Privacy Badger / all other extensions disabled, the referer error message always seems to appear and is probably due to A new default Referrer-Policy for Chrome: strict-origin-when-cross-origin UPDATE this now works for existing topics after adding an explicit Referrer-Policy to the originating site (e.g., https://www.comses.net) so for haproxy something like: http-response set-header Referrer-Policy "no-referrer-when-downgrade"
On Firefox and Chrome, pages with existing topics work but pages that attempt to create a new topic fail like this one: The Bronze Age Collapse model (BACO model).
I’ve changed our haproxy config to set response headers for Content-Security-Policy frame-ancestors and that fixed an invalid X-Frame-Options ALLOWALL not recognized error in Firefox but now the request times out and eventually results in a 400 Bad Request from our Discourse forum…
The error appears to be related to postMessage:
Failed to execute 'postMessage' on 'DOMWindow': The target origin provided ('https://forum.comses.net') does not match the recipient window's origin ('https://www.comses.net').
I’ll have more time to do a deeper dive towards the end of this month when I will have some more free time but wanted to brain dump while it’s still semi-fresh - hope someone else figures out a workaround in the meantime! 
The same happens to me. Hope anyone here could help a bit with thi error. In my case i have a test blog and an official blog…both made with Webflow…in test blog everything works ok but it throws this error in live blog…
### Error Embedding
Referer: `https://www.pynk.io/blog/what-to-invest-in-look-around-you`
The referer was either not sent, or did not match any of the following hosts:
[blank space here]Sorry for the late reply. Can you try adding discourseReferrerPolicy: 'no-referrer-when-downgrade' to the DiscourseEmbed object that’s set in the embed code snippet? There is a full example of a code snippet that adds that property here: Embedding Discourse Comments via Javascript.
If you try that, please let us know if it solves the issue for you.
I think this was resolved here: Embedding Discourse Comments via Javascript. In that case the problem was a missing www subdomain on the Discourse embeddable host record.
Edit: this issue has now been fixed in the core Discourse code. There is no longer a need to set the discourseReferrerPolicy variable to 'no-referrer-when-downgrade'. Discourse now sets the referrer policy to 'no-referrer-when-downgrade' by default. For details about this, see https://meta.discourse.org/t/embedding-discourse-comments-via-javascript/31963#setting-the-referrer-policy.
3 Likes
This may be posing issues with SSO. I have a current.discourse.example that is using sso.discourse.example as an SSO host. When you’re logged in, the topics-list shows correctly. But when you’re anonymous, they do not and display the above error. The /embed/topics?... URL shows a blank page.
I think – or hope – this should be fixed with:
Content-Security-Policy: frame-ancestors https://current.discourse.example https://sso.discourse.example;
1 Like