@@ -543,14 +543,19 @@ Apri il file vhost (quello con i segnaposto `@@@REDIRECT@@@`, `@@@DIRECTORY@@@`,
L'amministratore è identificato dal **`preferred_username` Keycloak**, controllato nei `<Location>` Apache. Per gestire più amministratori:
1. **In Keycloak** (Admin Console → Users): crea/verifica gli utenti con gli username che vuoi promuovere ad admin (es. `admin`, `alice`, `bob`). Imposta le credenziali normalmente.
2. **In Apache** (in tutti i blocchi `<Location "/cards/admin">`, `<Location "/cards/api/...">`): elenca gli username separati da spazi sulla riga `Require claim`:
2. **In Apache** (in tutti i blocchi `<Location "/cards/admin">`, `<Location "/cards/api/...">`): usa un blocco **`<RequireAny>`** con **una riga `Require claim` per ogni username**:
**Rimuovere un admin**: togli lo username dalla riga `Require claim` di Apache (e ricarica), oppure disabilita l'utente in Keycloak.
> ⚠ **Non usare la forma compatta `Require claim preferred_username:admin alice bob`** sulla stessa riga: su alcune versioni di `mod_auth_openidc` (incluse quelle in uso sui server MajorNet) il parser dei valori space-separated è buggy e finisce per accettare solo il primo username. Il blocco `<RequireAny>` con una riga `Require claim` per username delega la OR-logic ad Apache (`mod_authz_core`) e funziona affidabilmente. Stesso schema anche dentro `<LimitExcept GET HEAD>`.
**Rimuovere un admin**: togli la riga `Require claim preferred_username:<username>` corrispondente da `<RequireAny>` (e ricarica Apache), oppure disabilita l'utente direttamente in Keycloak.
#### Variante avanzata: ruoli Keycloak invece di username
@@ -570,7 +575,9 @@ In linea di principio si potrebbe gestire la lista degli amministratori interame
A quel punto, ogni nuovo admin si gestisce solo in Keycloak (assegnando/rimuovendo `cpc-admin`), senza toccare Apache.
**Quale scegliere:** se hai pochi amministratori stabili → resta con `preferred_username`, più semplice e già funzionante. Se ne hai molti o ruotano → vale la pena configurare il Mapper e passare al ruolo.
**Quale scegliere:** se hai pochi amministratori stabili → resta con `preferred_username` + `<RequireAny>`, più semplice e già funzionante. Se ne hai molti o ruotano → vale la pena configurare il Mapper e passare al ruolo.
> ⚠ **Sulle build MajorNet attuali anche `Require claim cpc_roles:cpc-admin` può fallire**, perché la stessa code-path che gestisce i valori space-separated gestisce anche il match contro claim di tipo array (`cpc_roles` è un array di stringhe). Se dopo aver configurato il Mapper e ricaricato Apache vedi che la `<Location>` viene bypassata (chiunque accede, anche senza il ruolo) → **resta sul pattern `<RequireAny>` con `preferred_username`**: è l'unico schema testato come affidabile su quella build.
### Pagine inesistenti → redirect alla home
Qualsiasi percorso non corrispondente a una pagina o API reale del progetto **non mostra una schermata d'errore**: viene reindirizzato alla home. È gestito lato Next da una rotta catch-all ([app/[...not_found]/page.tsx](app/%5B...not_found%5D/page.tsx)) che esegue `redirect('/')`. Le rotte reali (`/`, `/admin`, `/api/*`) hanno priorità; solo i path inesistenti finiscono lì. Le API inesistenti restano `404` (il redirect riguarda le pagine).
