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)
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)
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)
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)
Thank you. After editing the category and in Security tab adding “everyone” can “create/reply/see” the embedding works again.
إعجابَين (2)
إذن، بعد تحديث Discourse الأخير، تظهر جميع الصفحات المضمنة رسالة خطأ 
رسالة خطأ نموذجية نراها الآن تشبه هذا النص، والتي تبدو وكأنها تشير إلى أن المتصفح يقوم بإزالة معلومات الإحالة (referer) مما يتسبب في فشل تحققات كود التضمين الخاص بـ Discourse:
Referer: `https://www.comses.net/`
إما أن معلومات الإحالة (referer) لم تُرسل، أو أنها لم تطابق أيًا من المضيفين التاليين:
* www.comses.net/codebases/.*
مثال على الصفحة: Artificial Anasazi
على متصفح Chrome، حتى مع تعطيل Privacy Badger وجميع الإضافات الأخرى، تبدو رسالة خطأ الإحالة (referer) تظهر دائمًا، وربما يكون ذلك بسبب A new default Referrer-Policy for Chrome - strict-origin-when-cross-origin | Blog | Chrome for Developers تحديث: هذا يعمل الآن للمواضيع الموجودة بعد إضافة سياسة إحالة (Referrer-Policy) صريحة إلى الموقع المصدر (مثل https://www.comses.net)، لذا بالنسبة لـ haproxy، يمكن استخدام الأمر التالي: http-response set-header Referrer-Policy "no-referrer-when-downgrade"
على متصفح Firefox و Chrome، تعمل الصفحات التي تحتوي على مواضيع موجودة، لكن الصفحات التي تحاول إنشاء موضوع جديد تفشل مثل هذه الصفحة: The Bronze Age Collapse model (BACO model).
لقد قمت بتغيير إعدادات haproxy الخاصة بنا لتعيين رؤوس الاستجابة لـ Content-Security-Policy frame-ancestors، وقد تم إصلاح خطأ X-Frame-Options ALLOWALL not recognized غير الصالح في Firefox، لكن الآن الطلب ينقضي قبل إتمامه (timeout) وينتهي في النهاية بـ 400 Bad Request من منتدى Discourse الخاص بنا..
يبدو أن الخطأ مرتبط بـ postMessage:
فشل تنفيذ 'postMessage' على 'DOMWindow': الأصل المستهدف المقدم ('https://forum.comses.net') لا يطابق أصل نافذة المستلم ('https://www.comses.net').
سأكون لدي وقت أكثر للبحث بعمق في نهاية هذا الشهر عندما أكون لدي بعض الوقت الحر، لكن أردت مشاركة ما توصلت إليه بينما لا يزال الأمر طازجًا نسبيًا - آمل أن يتمكن شخص آخر من إيجاد حل بديل في هذه الأثناء! 
يحدث لي نفس الشيء. آمل أن يتمكن أي شخص هنا من المساعدة قليلاً في هذا الخطأ. في حالتي، لدي مدونة تجريبية ومدونة رسمية… وكلاهما تم إنشاؤه باستخدام Webflow… في المدونة التجريبية يعمل كل شيء بشكل صحيح، لكنه يظهر هذا الخطأ في المدونة الحية…
### خطأ في التضمين
مرجع: `https://www.pynk.io/blog/what-to-invest-in-look-around-you`
إما أنه لم يتم إرسال المرجع، أو أنه لا يطابق أيًا من المضيفات التالية:
[مساحة فارغة هنا]
آسف على التأخر في الرد. هل يمكنك تجربة إضافة discourseReferrerPolicy: 'no-referrer-when-downgrade' إلى كائن DiscourseEmbed الموجود في مقتطف كود التضمين؟ هناك مثال كامل لمقتطف كود يضيف هذه الخاصية هنا: Embed Discourse comments on another website via Javascript - #353.
إذا جربت ذلك، يرجى إخبارنا ما إذا كان ذلك يحل المشكلة بالنسبة لك.
أعتقد أن هذا تم حله هنا: Embed Discourse comments on another website via Javascript - #365. في تلك الحالة، كانت المشكلة هي غياب نطاق فرعي www في سجل المضيف القابل للتضمين في Discourse.
تعديل: تم إصلاح هذه المشكلة الآن في الكود الأساسي لـ Discourse. لم يعد هناك حاجة إلى تعيين متغير discourseReferrerPolicy إلى 'no-referrer-when-downgrade'. يقوم Discourse الآن بتعيين سياسة الإحالة إلى 'no-referrer-when-downgrade' بشكل افتراضي. لمزيد من التفاصيل حول هذا، راجع https://meta.discourse.org/t/embedding-discourse-comments-via-javascript/31963#setting-the-referrer-policy.
3 إعجابات
إضافة discourseReferrerPolicy حلّت المشكلة - شكرًا لك، @simon !! 
إعجاب واحد (1)
قد يتسبب هذا في مشاكل مع SSO. لدي current.discourse.example يستخدم sso.discourse.example كمضيف SSO. عندما تكون مسجّل الدخول، تُظهر قائمة المواضيع بشكل صحيح. لكن عندما تكون مجهولًا، لا تُظهر وتعرض الخطأ المذكور أعلاه. يُظهر عنوان URL /embed/topics?... صفحة فارغة.
أعتقد - أو أأمل - أن هذا يجب إصلاحه باستخدام:
Content-Security-Policy: frame-ancestors https://current.discourse.example https://sso.discourse.example;
إعجاب واحد (1)