Operator-configurable public-vs-private mode per standalone (forum, market, tasks, activities) #34

New issue

Open

opened 2026-05-02 08:52:38 +00:00 by padreug · 0 comments

padreug commented

2026-05-02 08:52:38 +00:00

Owner

Currently:

wallet, chat, castle always require login (no public view) — enforced in commit 4605703 with a hardcoded router guard.
forum, market, tasks, activities are public-browsable by default, with login-gated actions inside.

Per-deployment, the operator should be able to flip any of forum / market / tasks / activities into "always require login" mode (same behavior as wallet/chat/castle).

Proposed mechanism

Per-module env var, opt-in:

VITE_FORUM_REQUIRE_AUTH=true|false        # default: false (public)
VITE_MARKET_REQUIRE_AUTH=true|false       # default: false
VITE_TASKS_REQUIRE_AUTH=true|false        # default: false
VITE_ACTIVITIES_REQUIRE_AUTH=true|false   # default: false

In each app's app.ts, the existing router.beforeEach reads this and, when true, redirects any non-/login route to /login for unauth users — i.e. the same logic just shipped for wallet/chat/castle.

Acceptance criteria

Each of the 4 standalones has its own VITE_*_REQUIRE_AUTH env var, default false.
When set to true, behavior matches wallet/chat/castle (any non-login route → /login when unauth).
When false (or unset), current public-browsable behavior is preserved.
.env.example documents the four variables with comments.

Notes

Hub stays public (it's a launcher; the chakra tiles themselves point to standalones that can each enforce their own policy).
A user can be unauth on one standalone and auth on another — auth state is keyed to the LNbits token in localStorage; per-standalone redirect just affects routing, not the underlying session.

Currently: - **wallet, chat, castle** always require login (no public view) — enforced in commit 4605703 with a hardcoded router guard. - **forum, market, tasks, activities** are public-browsable by default, with login-gated actions inside. Per-deployment, the operator should be able to flip any of forum / market / tasks / activities into "always require login" mode (same behavior as wallet/chat/castle). ## Proposed mechanism Per-module env var, opt-in: ``` VITE_FORUM_REQUIRE_AUTH=true|false # default: false (public) VITE_MARKET_REQUIRE_AUTH=true|false # default: false VITE_TASKS_REQUIRE_AUTH=true|false # default: false VITE_ACTIVITIES_REQUIRE_AUTH=true|false # default: false ``` In each app's `app.ts`, the existing `router.beforeEach` reads this and, when true, redirects any non-`/login` route to `/login` for unauth users — i.e. the same logic just shipped for wallet/chat/castle. ## Acceptance criteria - Each of the 4 standalones has its own `VITE_*_REQUIRE_AUTH` env var, default false. - When set to true, behavior matches wallet/chat/castle (any non-login route → /login when unauth). - When false (or unset), current public-browsable behavior is preserved. - `.env.example` documents the four variables with comments. ## Notes - Hub stays public (it's a launcher; the chakra tiles themselves point to standalones that can each enforce their own policy). - A user can be unauth on one standalone and auth on another — auth state is keyed to the LNbits token in localStorage; per-standalone redirect just affects routing, not the underlying session.

padreug referenced this issue

2026-05-13 09:51:09 +00:00

Cross-cutting "teams" concept: targeted tasks, scoped budgets, and shared rosters #55

padreug added the

app:webapp

enhancement

labels

2026-05-17 21:24:02 +00:00