Standalone → hub SSO: token handoff for cross-origin nav back to launcher #48

New issue

Open

opened 2026-05-07 09:52:37 +00:00 by padreug · 0 comments

padreug commented

2026-05-07 09:52:37 +00:00

Owner

The hub → standalone direction already does a ?token=... query handoff (Hub.vue:64-67, server-validated via tryAdoptToken per #36). The reverse direction (standalone → hub) currently doesn't.

On subdomain deployments (<app>.${domain} → app.${domain}), the standalone and hub are different origins. If the hub later becomes auth-required (or surfaces auth-gated content like notification counts on the tiles per #32), navigating from a standalone to the hub via the <HubPill> would land logged-out unless cookies are set on the wildcard *.${domain} parent — which they currently aren't.

On path-mount deployments (app.${domain}/<app>/), this is a non-issue (same origin, same cookies/localStorage).

Scope

Decide between (a) wildcard cookies on *.${domain} (one-time nginx + LNbits config change) or (b) bidirectional ?token=... handoff so the standalone appends a token to the <HubPill> href when the user is authenticated.
If (b): mirror the existing Hub.vue pattern so behavior is symmetric.

Why now

Surfaced while planning the unified bottom-nav refactor (the <HubPill> is the trigger for this concern).

Depends on

The unified app shell being merged (<HubPill> lives there).

Acceptance

After the <HubPill> click on a subdomain-deployed standalone, the user lands on the hub already authenticated (no re-login).
Decision documented in docs/.
No regression to path-mount deployments.

The hub → standalone direction already does a `?token=...` query handoff (`Hub.vue:64-67`, server-validated via `tryAdoptToken` per #36). The reverse direction (standalone → hub) currently doesn't. On subdomain deployments (`<app>.${domain}` → `app.${domain}`), the standalone and hub are different origins. If the hub later becomes auth-required (or surfaces auth-gated content like notification counts on the tiles per #32), navigating from a standalone to the hub via the `<HubPill>` would land logged-out unless cookies are set on the wildcard `*.${domain}` parent — which they currently aren't. On path-mount deployments (`app.${domain}/<app>/`), this is a non-issue (same origin, same cookies/localStorage). ## Scope - Decide between (a) wildcard cookies on `*.${domain}` (one-time nginx + LNbits config change) or (b) bidirectional `?token=...` handoff so the standalone appends a token to the `<HubPill>` href when the user is authenticated. - If (b): mirror the existing `Hub.vue` pattern so behavior is symmetric. ## Why now Surfaced while planning the unified bottom-nav refactor (the `<HubPill>` is the trigger for this concern). ## Depends on - The unified app shell being merged (`<HubPill>` lives there). ## Acceptance - [ ] After the `<HubPill>` click on a subdomain-deployed standalone, the user lands on the hub already authenticated (no re-login). - [ ] Decision documented in `docs/`. - [ ] No regression to path-mount deployments.

padreug referenced this issue

2026-05-07 10:06:37 +00:00

feat(layout): unified app-shell primitives (Phase A) #51

padreug referenced this issue

2026-05-07 10:27:10 +00:00

feat(layout): adopt unified AppShell across hub + 7 standalones (Phase B) #52

padreug added the

app:webapp

enhancement

labels

2026-05-17 21:23:34 +00:00