Tecnoblog 使用 Discourse 评论系统的体验

Previously, full app embeds loaded on a third-party domain could not see the for…um's session cookie, leaving users effectively logged out, and `showLogin` only opened a dead-end `/login` tab the iframe never reacted to. This adds an `embed_full_app_signin_flow` site setting (on by default, gated to full app embed mode) that intercepts logged-out actions inside the iframe with a guided flow: bridge storage access if the iframe's cookie jar is partitioned, then either reload (if the user is already signed in elsewhere) or open a top-level sign-in tab and watch the session via polling. ## Flow 1. User clicks an auth-gated action (Reply CTA, Like, etc.). `showLogin` / `showCreateAccount` and the embed-topic-footer reply CTA route into the new `embed-auth-flow` service. 2. **If `document.hasStorageAccess()` is `false`** — Safari ITP, Firefox Total Cookie Protection, Chrome's 3p cookie phaseout — an in-iframe modal asks the user to share their session. Confirming calls `requestStorageAccess()` (synchronously inside the click handler so user activation is preserved). 3. Once we have access, the service probes `/session/current.json`. If the user is already signed in elsewhere (common Firefox ETP scenario), the iframe reloads to pick up the session — no popup. 4. Otherwise, a sign-in modal opens a top-level `/login?embed_signin_callback=1` (or `/signup`) tab and shows a waiting state with a spinner. The iframe polls `/session/current.json` every 3s for up to 5 min. 5. When polling sees a logged-in response, the iframe reloads. The popup self-closes once it has a session, driven by the `embed_signin_callback` query param + sessionStorage flag. ## Why polling instead of `postMessage` The popup-side callback originally posted a success message back to the opener. Discourse's default `Cross-Origin-Opener-Policy` (`same-origin-allow-popups`) typically mismatches an embedding host's (`unsafe-none`), which severs `window.opener` on the popup's very first load — and any OAuth provider redirect amplifies this. Polling sidesteps the whole opener relationship and works regardless of COOP, OAuth, or the user opening the link in a new tab. ## Setting - `embed_full_app_signin_flow` (boolean, default `true`, in the `embedding` area). - The flow assumes the iframe can receive its cookies after popup sign-in — true when the embed is **same-site to the host page** (any SameSite setting) or when `same_site_cookies = "None"` is configured for cross-site embeds. We trust the admin to enable this only on a compatible deployment. ## Implementation notes - **Browser-agnostic storage access.** `hasStorageAccess()` is the single signal — `true` on same-site/same-origin embeds (no prompt needed), `false` whenever the iframe's cookie jar is partitioned. No browser sniffing. - **User activation preserved.** The modal uses native `<button {{on "click" handler}}>` rather than `service:dialog`, so `requestStorageAccess()` and `window.open()` see a live activation token in the click handler. - **No reload after storage access.** `requestStorageAccess()` grants access for the current document; we chain directly into the next step in the same execution. Reloading would put the iframe back in partitioned mode in most browsers. - **Popup self-close is param-driven, not opener-driven.** The callback initializer keys off `?embed_signin_callback=1` alone — `window.opener` is unreliable thanks to COOP. - **API-unsupported fallback.** Without `document.requestStorageAccess`, the service opens a plain top-level login tab (no callback param) instead of trapping the user in a popup that cannot bridge cookies. - **Storage access denial is a dead-end on purpose.** The catch handler does not chain to a sign-in popup, since a sign-in tab cannot help an iframe that lacks storage access. The user retries the action to be re-prompted. - **Waiting modal.** While polling, the iframe shows a spinner and "Waiting for sign-in" message. Cancel stops the poll and closes the popup; the modal auto-dismisses on timeout. ## Tests `tests/unit/services/embed-auth-flow-test.js` covers gating, the partitioned vs. non-partitioned split, the storage-access → sign-in chain, the already-signed-in → reload path, denial behaviour, popup URL routing, and the API-unsupported fallback.

这是一个复杂的变更，但我们希望能带来更好的用户体验。

Thiago_Mobilon · 2026 年5 月 7 日 20:14

我发现了另一个 UI 错误：

当我点击编辑帖子时，iframe 底部出现了一个空白区域，里面没有任何内容。“标准”表单仍然处于打开状态，但我的评论不在其中，无法进行编辑。此外，显示帖子数量的元素向左移动了。

Falco · 2026 年5 月 7 日 20:27

听起来像是 AI Bot composer 的一个 bug 对吧 @keegan ？

keegan · 2026 年5 月 8 日 20:29

这应该已经通过以下链接解决了：

github.com/discourse/discourse

FEATURE: Add post editing support to docked composers (#39858)

committed 06:11PM - 08 May 26 UTC

keegangeorge

+277 -18

**Previously**, clicking "edit" on a post in embed mode or an AI bot PM would op…en the standard floating composer. **This change** adds inline edit support to both the embed-mode and AI bot docked composers, intercepting the edit action via app events and handling the PUT request directly, so users never leave the docked composer flow. ---- Embed Mode: <img width="670" height="401" alt="embed-mode" src="https://github.com/user-attachments/assets/bd11afc6-b7f0-456d-b0be-ddb48fdd964e" /> AI Bot: <img width="786" height="230" alt="ai-bot" src="https://github.com/user-attachments/assets/7c63fa08-cb03-4a5a-9405-b0f204264d02" />

Thiago_Mobilon · 2026 年5 月 11 日 23:48

我刚才看了一下统计数据，不确定一切是否按预期正常运行。我在“嵌入视图”（Embedded Views）下看到的每日页面浏览量不到 400 次。

作为背景参考，在我们切换到完整应用嵌入之前，整个社区每天的页面浏览量约为 8,000 次——而自上线以来，这个数字已增长了 5 倍以上。

这个差异难道不应该反映在“嵌入视图”部分吗？

Falco · 2026 年5 月 15 日 17:09

Thiago_Mobilon:

5. 登录摩擦

当前的流程有点像是转化率的杀手：用户点击登录 → 打开新标签页 → 完成登录 → 用户停留在社区主页。回到博客文章页面，iframe 仍然显示未登录状态，直到用户手动刷新整个页面。这是一个令人困惑的循环，导致人们在评论前放弃并离开。

自从启用新的嵌入功能后，我们的每日注册量翻了一番以上，这很好。然而，我们的参与度指标没有任何变化。事实上，我们的DAU/MAU 下降了——我们有更多登录用户，但他们并没有互动。像“每日活跃用户”、“新贡献者”和“发帖数”等指标都没有任何增长。

这证明人们想要参与讨论，但他们在登录循环中迷失了方向，在能够实际评论之前就放弃了帖子。

这个问题现在已经修复，请更新以获取新的登录流程。

github.com/discourse/discourse

FEATURE: Add in-iframe sign-in flow for full app embed mode (#39756)

main ← embed-full-app-signin-flow

merged 04:07PM - 15 May 26 UTC

xfalcox

+644 -4

Previously, full app embeds loaded on a third-party domain could not see the for…um's session cookie, leaving users effectively logged out, and `showLogin` only opened a dead-end `/login` tab the iframe never reacted to. This adds an `embed_full_app_signin_flow` site setting (on by default, gated to full app embed mode) that intercepts logged-out actions inside the iframe with a guided flow: bridge storage access if the iframe's cookie jar is partitioned, then either reload (if the user is already signed in elsewhere) or open a top-level sign-in tab and watch the session via polling. ## Flow 1. User clicks an auth-gated action (Reply CTA, Like, etc.). `showLogin` / `showCreateAccount` and the embed-topic-footer reply CTA route into the new `embed-auth-flow` service. 2. **If `document.hasStorageAccess()` is `false`** — Safari ITP, Firefox Total Cookie Protection, Chrome's 3p cookie phaseout — an in-iframe modal asks the user to share their session. Confirming calls `requestStorageAccess()` (synchronously inside the click handler so user activation is preserved). 3. Once we have access, the service probes `/session/current.json`. If the user is already signed in elsewhere (common Firefox ETP scenario), the iframe reloads to pick up the session — no popup. 4. Otherwise, a sign-in modal opens a top-level `/login?embed_signin_callback=1` (or `/signup`) tab and shows a waiting state with a spinner. The iframe polls `/session/current.json` every 3s for up to 5 min. 5. When polling sees a logged-in response, the iframe reloads. The popup self-closes once it has a session, driven by the `embed_signin_callback` query param + sessionStorage flag. ## Why polling instead of `postMessage` The popup-side callback originally posted a success message back to the opener. Discourse's default `Cross-Origin-Opener-Policy` (`same-origin-allow-popups`) typically mismatches an embedding host's (`unsafe-none`), which severs `window.opener` on the popup's very first load — and any OAuth provider redirect amplifies this. Polling sidesteps the whole opener relationship and works regardless of COOP, OAuth, or the user opening the link in a new tab. ## Setting - `embed_full_app_signin_flow` (boolean, default `true`, in the `embedding` area). - The flow assumes the iframe can receive its cookies after popup sign-in — true when the embed is **same-site to the host page** (any SameSite setting) or when `same_site_cookies = "None"` is configured for cross-site embeds. We trust the admin to enable this only on a compatible deployment. ## Implementation notes - **Browser-agnostic storage access.** `hasStorageAccess()` is the single signal — `true` on same-site/same-origin embeds (no prompt needed), `false` whenever the iframe's cookie jar is partitioned. No browser sniffing. - **User activation preserved.** The modal uses native `<button {{on "click" handler}}>` rather than `service:dialog`, so `requestStorageAccess()` and `window.open()` see a live activation token in the click handler. - **No reload after storage access.** `requestStorageAccess()` grants access for the current document; we chain directly into the next step in the same execution. Reloading would put the iframe back in partitioned mode in most browsers. - **Popup self-close is param-driven, not opener-driven.** The callback initializer keys off `?embed_signin_callback=1` alone — `window.opener` is unreliable thanks to COOP. - **API-unsupported fallback.** Without `document.requestStorageAccess`, the service opens a plain top-level login tab (no callback param) instead of trapping the user in a popup that cannot bridge cookies. - **Storage access denial is a dead-end on purpose.** The catch handler does not chain to a sign-in popup, since a sign-in tab cannot help an iframe that lacks storage access. The user retries the action to be re-prompted. - **Waiting modal.** While polling, the iframe shows a spinner and "Waiting for sign-in" message. Cancel stops the poll and closes the popup; the modal auto-dismisses on timeout. ## Tests `tests/unit/services/embed-auth-flow-test.js` covers gating, the partitioned vs. non-partitioned split, the storage-access → sign-in chain, the already-signed-in → reload path, denial behaviour, popup URL routing, and the API-unsupported fallback.

Thiago_Mobilon · 2026 年5 月 15 日 21:10

我认为新的嵌套回复功能可能与嵌入模式不兼容。

我启用了一个主题的嵌套回复功能进行测试，结果iframe没有加载评论部分，而是在帖子内部加载了帖子。

Thiago_Mobilon · 2026 年6 月 18 日 23:14

广告插件还会在嵌入版本中插入广告，这会导致布局错乱。

我认为我们可以保留“帖子底部”选项（即帖子之间出现的广告），因为其格式很适合嵌入场景（通常是中等矩形：300x250）。

不过，其他广告位在嵌入版本中并不合适，因此最好将其移除。

Thiago_Mobilon · 2026 年6 月 18 日 23:59

我配置了“帖子底部”插槽，以查看其在嵌入中的显示效果，结果在桌面视图中生成了水平滚动条——尽管我只启用了远小于嵌入宽度的尺寸。

顺便提一下，我还注意到在移动端，帖子的右边距比左边距更宽（我认为这与广告无关）。

话题		回复	浏览量
Embed Discourse comments on another website via Javascript Integrations embedding , how-to	127	304572	2026 年6 月 2 日
Embed Discourse comments with on-page commenting? Feature	32	8129	2019 年1 月 19 日
Discourse Comments stuck on "Loading..." Support	22	2218	2024 年9 月 18 日
Embed Discourse as a full comment system on your site Announcements embedding	24	2261	2026 年6 月 2 日
Should Discourse make an effort to become a viable comment platform? Community Building	62	5468	2026 年3 月 25 日

Tecnoblog 使用 Discourse 评论系统的体验

相关话题