Tecnoblog의 Discourse 댓글 사용 경험

Falco · 5월 15, 2026, 5: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.

글		댓글	조회수
Embed Discourse comments on another website via Javascript Integrations embedding , how-to	127	305335	6월 2, 2026
Embed Discourse comments with on-page commenting? Feature	32	8296	1월 19, 2019
Discourse Comments stuck on "Loading..." Support	22	2302	9월 18, 2024
Should Discourse make an effort to become a viable comment platform? Community Building	62	5769	3월 25, 2026
Cannot get embedding to work Support	11	2687	8월 31, 2021

Tecnoblog의 Discourse 댓글 사용 경험

Related topics