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:
2026-08-28 16:17:10 +02:00
co-authored by Claude Sonnet 5
parent c2667b3bfe
commit 7fc72c1cdb
+11
View File
@@ -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