That was!! You save my day… Thanks a lot!
Could be wrong, but doesn’t this open up a x-site security vulnerability? See:
2 个赞
I don’t know much in these matters, but here is my reasoning:
- “same site cookie” is enabled by default, so it is probably much better this way.
- “same site cookie” can be disabled, so it’s probably not a security hole by itself, rather a weakness that could be exploited in conjunction with others. Disable it at your own risks.
Anyone understands why disabling same site cookie enforcement prevents users from log in within an iframe?
我们能否获得对 Discourse 在 iframe 中的官方支持？
编辑：哎呀，抱歉，我没意识到我发帖晚了两年。
这种情况几乎不可能得到支持。
2 个赞
Jeff，
首先：Discourse 非常棒，感谢你们开发它！
其次：是否有文档说明了在 iframe 中嵌入 Discourse 时可能遇到的具体问题，或者原则上会受到哪些限制？
谢谢！
你好，Adam，好久不见，我来这里试着回答一下。
使用 <iframe> 非常容易出错，会让 Discourse 变得难以使用，并引入许多难以排查的 bug。此外，它往往会在 Discourse 内部形成独立的“窗口”，导致诸如在大主题中滚动浏览等功能失效。简而言之，iframe 会沙盒化 Discourse 的许多功能。
如果你正在考虑使用 iframe，一个较好的方案是在你的论坛顶部添加一个与你的网站/应用/门户其余部分相匹配的页眉，包括导航链接。当用户点击进入论坛时，他们会看到相似的导航，但此时位于托管在其他地方的不同 URL 上。当他们点击页眉中的非论坛链接时，就会返回到网站/应用/门户中。
希望这能帮到你。
2 个赞
感谢您的回复！
您能否具体说明预期会出现哪些问题？或者具体解释一下 iframe 的上下文为何会导致严重问题？
这里的“窗口化”（window）具体指什么？
这是我们为主要的讨论区计划采用的方案，但对于这个具体用例来说存在一些问题。我们运营的是在线课程。每门课程都在我们网站上一个具有特定主题和私密性的区域中进行。课程内容包含教材、视频、课程表以及讨论区。学生完成课程后，可以继续与同班同学进行他们已开始的讨论。他们还会被加入一个通用的课程校友讨论组，并受邀加入我们更大规模的公开讨论论坛。
针对我们的用例，上述建议的方案存在两个问题：
-
我们网站上课程区域的风格（页头、样式、侧边栏等）与我们希望为 Discourse 整体采用的风格并不一致。为了适应这一点，我们需要能够为每个类别使用不同的样式和主题内容，但这似乎无法实现。
-
在我们当前的（非 Discourse）实现中，课程讨论区包含样式、页头和侧边栏菜单。这是一个低干扰的空间，学生可以专注于课程内容，并顺畅地在讨论、教材、视频等内容之间切换。据我所知，要修改 Discourse 以复制这种沉浸式环境是非常困难的。如果情况并非如此，我很乐意了解如何做到这一点！
感谢您的帮助，
Adam
这是可行的。body 元素会包含一个指示当前类别的类名，使您能够利用 SCSS 中的嵌套选择器轻松限定主题范围。
一般来说，我建议您为课程区域添加几个 Discourse 小部件，例如我们支持的嵌入话题列表功能，相关文档请参阅 在另一个网站中嵌入 Discourse 话题列表。这样，学生可以看到与其当前课程页面相关的最新讨论列表，并且只需点击一次即可在新浏览器标签页中加入讨论！
3 个赞
你好，Falco，
感谢你的回复，也请原谅我回复得有些晚了。
不幸的是，我们的课程实现方式比自定义 CSS 作用域所能容纳的复杂得多，除非进行大量的变通处理。例如，头部菜单包含一个下拉列表，显示当前用户已注册的课程。这是根据登录用户从 WordPress 数据库中动态生成的，因此在 Discourse 中很难复制这一功能。
课程区域的侧边栏菜单包含指向各种课程内容的链接，这些内容特定于某一门课程。如果我理解正确的话，要实现你所描述的功能，所有课程的所有这些内容都需要硬编码到主题中，然后根据 body 类通过 CSS 显示或隐藏。是这样吗？
一种可行的方法是使用 Discourse 中的一些客户端 JavaScript，从我们的 API 拉取内容并显示出来。是否可以在 Discourse 中添加自定义脚本来向其他服务器发起 XmlHttpRequest？你有没有看到任何可能导致此方案不可行的原因？
我仍然希望能得到这个问题的答复。
谢谢！
是的，这是可行的。只需注意不要让这些请求阻塞页面的渲染。
2 个赞