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!
这可能会晚一些，但我遇到了同样的问题，本来很希望在这里得到解答。我的问题只在用 Firefox 时出现，Chrome 没问题。我通过把嵌入内容的网站添加到“CORS 来源”设置中解决了它。相关线索在这里。
2 个赞
我刚刚注意到，我们的网站也遇到了这个问题，但仅出现在新帖子中，对于已经创建了对应主题帖子的现有帖子则没有此问题。Invalid X-Frame-Options 头部似乎更多是 Firefox 的警告而非实际错误，因为它始终会出现，即使嵌入成功也是如此。
一个正常工作的示例（使用嵌入功能时，该主题帖子已存在）：
而以下落地页：
最终会从我们的 Discourse 实例收到 400 错误请求响应。
我一直在浏览这些论坛和文档，试图找出原因，但尚未找到任何相关信息。我曾以为这可能与我们在嵌入负载中包含了 Discourse 用户名有关，但即使是那些已正确同步的用户创建的内容也会出现此问题（例如：https://www.comses.net/events/584/）。
我已检查以下内容：
- 已设置
DISCOURSE_ENABLE_CORS: true - Discourse 设置中的 CORS 主机配置正确，并使用了 https
- 允许的主机已正确设置（此外，嵌入功能对于已创建的 Discourse 帖子仍正常工作）
我还需要考虑检查其他哪些方面？我唯一能想到的其他可能性是，我们最近将网站与 Cloudflare 进行了集成，因此可能需要对 Cloudflare 进行某些配置才能使一切正常运行。但我仍然感到困惑，为什么现有主题帖子能正常工作……
您可以尝试暂时禁用 Cloudflare，看看是否有帮助。这很容易操作…
1 个赞
好主意，我在我们的测试站点上试过了，但遗憾的是问题仍未解决。
在 Chrome 中，我看到如下错误：
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').
（来自 https://test.comses.net/codebases/f0613922-9cb1-4656-a26c-af57f823fb69/releases/3.2.0/）
这里的其他人似乎通过确保 DiscourseEmbed.discourseEmbedUrl 与引用 URL 一致解决了此问题，但我已确认该值仍然正确。我查看了 Discourse 日志（我应该查看 /var/discourse/shared/standalone/log/rails/production.log 吗？），但那里也没有发现任何错误。还有其他建议的排查方向吗？
以下是 Discourse 日志中的一个示例：
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)
我遇到了同样的问题。你可以在这里实时看到：Making sure you're not a bot! @mock/mock - Fedora Discussion 的讨论。请注意，discussion.fedoraproject.org 是一个付费实例，由 Discourse 作为服务提供。让我感到困惑的是，讨论有时能加载，有时却不行。我几乎总能在 Firefox（版本 80）的隐私模式下复现此问题。开发者工具显示：
加载“https://discussion.fedoraproject.org/embed/comments?embed_url=https%3A%2F%2Fcopr.fedorainfracloud.org%2Fcoprs%2Fg%2Fmock%2Fmock%2F”时发现了无效的 X-Frame-Options 响应头：“ALLOWALL”不是一个有效的指令。
确实，文档 X-Frame-Options header - HTTP | MDN 并未将 ALLOWALL 识别为有效值。
看起来您链接到的主题（https://discussion.fedoraproject.org/t/mock-mock/3107）位于一个受保护的分类中——作为匿名用户，我无法访问它。只要您的 Discourse 论坛和您的网站共享相同的根域名，我预计已登录论坛的用户可以加载嵌入式评论，而未登录论坛的用户则无法加载。这听起来是否符合您所观察到的情况？
1 个赞
我预计已登录论坛的用户会加载嵌入式评论，而未登录的用户则无法加载。这听起来是否与您看到的情况相符？
确实如此。我可以在 Google Chrome 和 Firefox 中复现此行为。不过，在这两个浏览器的隐私模式下讨论无法加载，我不确定这是否有意义。但我认为这仍然提示我们需要更新分类，以便所有人都能看到。
1 个赞
谢谢。在编辑分类并在“安全”选项卡中为“所有人”添加“创建/回复/查看”权限后，嵌入功能恢复正常。
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 更新：现在，通过在源站点（例如 https://www.comses.net）添加显式的 Referrer-Policy，现有主题已可以正常工作。对于 haproxy，可以配置类似：http-response set-header Referrer-Policy "no-referrer-when-downgrade"
在 Firefox 和 Chrome 上，包含现有主题的页面可以正常工作，但尝试创建新主题的页面会失败，例如：https://www.comses.net/codebases/dea16fd0-f56b-420e-a4c2-d151ffa3f2a8/releases/1.1.0/。
我已修改了我们的 haproxy 配置，以设置 Content-Security-Policy frame-ancestors 响应头，这解决了 Firefox 中无效的 X-Frame-Options ALLOWALL not recognized 错误，但现在请求超时，最终导致我们的 Discourse 论坛返回 400 Bad Request。
该错误似乎与 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').
我将在本月底有更多时间进行更深入的研究，届时我会有一些空闲时间，但我想趁现在记忆还比较清晰时先分享这些思路——希望在此期间有人能找出变通方案！
我也遇到同样的问题。希望有人能帮忙解决这个错误。在我的情况下，我有一个测试博客和一个官方博客，两者都是使用 Webflow 制作的。测试博客一切正常，但在官方博客中却出现此错误：
### 嵌入错误
引用来源：`https://www.pynk.io/blog/what-to-invest-in-look-around-you`
未发送引用来源，或引用来源与以下任何主机不匹配：
[此处为空白]
抱歉回复晚了。您能否尝试在嵌入代码片段中设置的 DiscourseEmbed 对象里添加 discourseReferrerPolicy: 'no-referrer-when-downgrade'？这里有一个包含该属性的完整代码片段示例：https://meta.discourse.org/t/embedding-discourse-comments-via-javascript/31963/353。
如果您尝试了上述方法，请告知我们是否解决了您的问题。
我认为这个问题在这里已经解决了：https://meta.discourse.org/t/embedding-discourse-comments-via-javascript/31963/365。在那种情况下，问题出在 Discourse 可嵌入主机记录中缺少 www 子域名。
编辑：此问题现在已在 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 带来问题。我当前的 discourse 实例 current.discourse.example 使用 sso.discourse.example 作为 SSO 主机。当您登录时，主题列表显示正常。但作为匿名用户时，它们无法显示并出现上述错误。/embed/topics?... URL 显示为空白页面。
我认为——或者说希望——可以通过以下方式修复：
Content-Security-Policy: frame-ancestors https://current.discourse.example https://sso.discourse.example;
1 个赞