Overview

Autenticazione & Autorizzazioni

Questa sezione raccoglie il flusso login e i livelli autorizzativi principali: UI di accesso, metadata (tabella/colonna/menu) e route-guard lato host Angular.

1) Login

Screen riferimento:

manual__auth_login__01.png: schermata login (username/password + azioni auth).

Captcha (abilitazione):

Il captcha viene abilitato quando entrambe le chiavi sono valorizzate:
captcha_public_key
captcha_private_key
La configurazione pre-login viene esposta da GET /api/Meta/AuthConfig (captchaEnabled, captchaSiteKey).

Registrazione (abilitazione):

La registrazione viene esposta in UI quando registrationEnabled = true nella AuthConfig.
Nel backend, registrationEnabled dipende da email-sender-address-registration valorizzato.
In login compare il link Registrati; nel form register sono previsti username, email, password e (se attivo) captcha.

Recupero password:

In login e disponibile il link Password dimenticata?.
La richiesta reset usa MetaService.requestPasswordReset e invia email con link contenente token.
Chiavi minime da configurare per il flusso email:
email-host
email-port
email-ssl
email-user
email-pwd
email-sender-address-registration
site-url (base URL usata per costruire il link di reset).

AppSettings consigliati (estratto):

Snippet 1JSON

{
  "AppSettings": {
    "captcha_public_key": "your-public-key",
    "captcha_private_key": "your-private-key",
    "email-sender-address-registration": "no-reply@your-domain.tld",
    "email-host": "smtp.your-domain.tld",
    "email-port": "587",

1bis) Modello flag admin (server + client)

Il framework distingue tre flag con granularita' crescente, valutati in sequenza dal piu' restrittivo al piu' permissivo:

Flag	Sorgente DB	Scope	Usato in
`isSuperAdmin`	`ruoli.superadmin` (bit)	Privilegio massimo: puo' modificare metadati di progetto	Gate server su tutte le mutazioni metadata (`RawHelpers.checkAdmin`) + UI-gate client (`UserInfoService.isUserAdmin` / `isCurrentUserAdmin`)
`isRoleAdmin`	`ruoli.admin` (bit)	Ruolo "Amministratore" nominale (es. seed `id_ruolo=2`)	Solo fallback-grant per-route (non supera `checkAdmin`)
`isAdmin` (legacy)	`utenti.isAdmin` (bit)	Flag per-utente storico	Solo fallback-grant per-route (non supera `checkAdmin`)

Le due semantiche applicative:

Gate "mutazione metadata" (scaffolding, save boardcontent, edit colonne/tabelle metadata, ecc.):

- server: RawHelpers.checkAdmin(uid) in Helpers.cs — fallisce con AuthenticationException("Need administrative rights!") se !user.isSuperAdmin.

- client: UI nasconde/disabilita le azioni lette da UserInfoService.isUserAdmin(userLike) che ritorna userLike.isSuperAdmin.

- Gli endpoint coinvolti sono ~40 (vedi MetaService.cs, metaModelRaw.cs, scaffolding.asmx.cs, _Metadati_methods_xml.cs).

Fallback-grant per-route (quando una tabella ha md_grant_by_default = false e nessun grant esplicito utente/ruolo/azienda):

- server: applyTableRestrictions in _Metadati_Tabelle.cs — concede view/edit/insert/delete se user.hasAdminGrant, dove:

Snippet 2text

    hasAdminGrant = isSuperAdmin OR isRoleAdmin OR isAdmin

- La cascade e' permissiva per retrocompatibilita': un superadmin supera sempre, ma anche un ruolo admin=1 o un utente con il vecchio utenti.isAdmin=1 resta autorizzato.

Payload k-user (cookie / sessionStorage) post-login contiene entrambi i flag:

Snippet 3JSON

{
  "user_id": 100274,
  "user_name": "admin",
  "role": "Admin",
  "role_id": 1,
  "isAdmin": true,
  "isSuperAdmin": true,

Note operative:

Il flag legacy utenti.isAdmin resta popolato sul modello user ma non va piu' usato per decisioni di autorizzazione nuove: preferire sempre isSuperAdmin (gate) o hasAdminGrant (fallback permissivo).
Lato Angular host, il route-guard roleRouteCanMatchGuard usa la label role (stringa "Admin" / "Amministratore" / ecc.) per match con FRAMEWORK_ROUTE_ROLE_RULES. E' una decisione di routing applicativa, indipendente dai flag DB.

2) Metadati autorizzazioni: tabelle, colonne, menu

Screen ripresi dalla documentazione metadata esistente:

metadata-integration__metadata-editor-auth-table__desktop.png: autorizzazioni tabella.
metadata-integration__metadata-editor-auth-table-edit-popup__desktop.png: popup edit autorizzazione tabella.
metadata-integration__metadata-editor-auth-column__desktop.png: autorizzazioni colonna.
metadata-integration__metadata-editor-auth-column-edit-popup__desktop.png: popup edit autorizzazione colonna.
metadata-integration__metadata-menu-management__desktop.png: gestione menu metadata.
metadata-integration__metadata-menu-management-edit-popup__desktop.png: popup edit voce menu.

Metadati coinvolti:

_Metadati_Utenti_Autorizzazioni_Tabelle: permessi view/edit/insert/delete a livello route/tabella.
_Metadati_Utenti_Autorizzazioni_Colonne: permessi field-level (es. editabilita/required per ruolo o utente).
_metadati__menu: visibilita/navigazione voci menu in combinazione con i permessi route.

3) Utilizzo route-guard (host project)

Obiettivo: bloccare route riservate in base ai ruoli utente e reindirizzare a /unauthorized.

File host da modificare (esempio WuicTest):

C:\src\Wuic\WuicTest\wwwroot\src\app\routing\route-role-map.ts
C:\src\Wuic\WuicTest\wwwroot\src\app\routing\role-route.guard.ts
C:\src\Wuic\WuicTest\wwwroot\src\app\wuic-bridges\routes.ts
C:\src\Wuic\WuicTest\wwwroot\src\app\app.routes.ts
C:\src\Wuic\WuicTest\wwwroot\src\app\component\unauthorized\unauthorized.component.ts

Esempio 1: mappa regole ruolo/route

Snippet 4ts

export const FRAMEWORK_ROUTE_ROLE_RULES: RouteRoleRule[] = [
  { key: 'designer', routePattern: 'designer', roles: ['admin'] },
  { key: 'workflow-designer', routePattern: 'workflow-designer', roles: ['admin'] },
  { key: 'dashboard', routePattern: ':route/dashboard', roles: ['admin'] },
  { key: 'report-designer', routePattern: ':route/report-designer', roles: ['admin'] }
];

Esempio 2: aggancio guard alle route

Snippet 5ts

{
  path: ':route/dashboard',
  loadComponent: () => import('wuic-framework-lib-src/component/designer/designer.route.component').then((m) => m.DesignerRouteComponent),
  canMatch: [menuRouteAccessCanMatchGuard, roleRouteCanMatchGuard],
  canActivate: [menuRouteAccessCanActivateGuard, roleRouteCanActivateGuard],
  data: { breadcrumbs: 'dashboard', roleRuleKey: 'dashboard' }
}

Esempio 3: redirect su pagina unauthorized

Snippet 6ts

return router.createUrlTree(['/unauthorized'], {
  queryParams: { from: attemptedPath || '/' }
});