Documento in CLAUDE.md il nuovo meccanismo di login admin
Spiega che l'admin gating in-app ora passa da un vero login Strapi invece del nome scelto, e che il limite di sicurezza (RLS Supabase ancora aperta) resta, con puntatore allo schema auth dormiente già presente nelle migration. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This commit is contained in:
@@ -130,6 +130,17 @@ Supabase Auth (GoTrue), attached via middleware rather than per-request boilerpl
|
||||
`auth-attacher.ts` / `auth-middleware.ts` above. Self-hostable; not tied to Lovable-proprietary
|
||||
auth.
|
||||
|
||||
**Admin gating in-app** (`/scout`, `/eventi`, sollecito presenze, export CSV scout) no longer
|
||||
comes from picking a hardcoded player name — it's a client-side "admin mode" unlocked by logging
|
||||
into Strapi's real admin account (`src/lib/admin-auth.ts`'s `loginAdmin()`, calling Strapi's
|
||||
`/admin/login`; `useAdminSession()` reads a locally-stored flag with an 8h expiry, UI via
|
||||
`<AdminLogin />` in `/profilo` and inside the reserved screens). This still only gates the app's
|
||||
UI — Supabase tables involved (`eventi_app`, `scout_live`, etc.) keep their existing open RLS
|
||||
(anon can read/write directly via the public `anon` key), so it does not stop someone hitting the
|
||||
Supabase REST API directly. Closing that fully would mean real per-user Supabase Auth + RLS tied
|
||||
to it — there's a dormant, unused schema for this already in an early `supabase/migrations/*.sql`
|
||||
(`app_role` enum, `user_roles`, `has_role()`), superseded by the simpler open tables in use today.
|
||||
|
||||
## Project memory (`mem/`)
|
||||
|
||||
`mem/index.md` indexes feature-level design notes (`mem/features/*.md`) — currently the portability
|
||||
|
||||
Reference in New Issue
Block a user