STORY-478: Google OAuth login cittadini — approccio e decisioni

[Malebestia]

Contesto

Vogliamo abilitare il login con Google per i cittadini dalla pagina FO /it/auth/login.

L'infrastruttura Socialite esiste già in questo modulo ma è cablata solo per il BO (/admin/login/{provider}). Dobbiamo esporla anche nel FO.

Domande aperte

1. Route FO: prefisso /it o route dedicata?

Le route Socialite attuali usano /admin/login/{provider}. Per il FO potremmo:

• A: Aggiungere una route separata tipo /auth/social/{provider} nel gruppo FO localizzato
• B: Riutilizzare la stessa route callback /sso/{provider}/callback con redirect diverso in base al guard

2. Redirect post-login per i cittadini

Dopo il login OAuth il cittadino deve tornare a /it (homepage FO) e non alla dashboard Filament. Dove gestiamo il redirect? In ProcessCallbackController o in GetLoginRedirectRouteAction?

3. Registrazione automatica

config/socialite.php ha registration => true. Se un cittadino si logga con Google per la prima volta viene creato automaticamente un account. Confermiamo questo comportamento?

4. Separazione FO / BO

STORY-461 copre SSO per operatori BO (Google Workspace, Microsoft Entra, milestone M9). Questa story è per cittadini FO con account Google personale. Dobbiamo assicurarci che i due flussi non si sovrappongano (guard diversi: web vs admin).

Riferimenti

• Issue: laraxot/module_user_fila5#(vedi issue correlata)
• STORY-461: OAuth2 SSO operatori BO
• app/Http/Controllers/Socialite/ProcessCallbackController.php
• app/Actions/Socialite/GetLoginRedirectRouteAction.php
• config/socialite.php

[Malebestia]

Valutazione modifiche apportate

File	Modifica	Era necessaria?	Perché
routes/socialite.php	Aggiunta route /auth/social/{provider}	✅ Sì	Senza questa, il bottone puntava a /admin/login/google — inaccessibile ai cittadini
social-login.blade.php — route	oauth.redirect → oauth.fo.redirect	✅ Sì	Conseguenza diretta della nuova route
social-login.blade.php — traduzioni	auth.social.google → auth.login.google	✅ Sì	auth.social.google restituisce un array → TypeError in produzione
login.blade.php (Sixteen)	Aggiunto SocialLoginWidget	✅ Sì	Il bottone non sarebbe mai apparso
GetDomainAllowListAction.php	filament-socialite.domain_allowlist → socialite.domain_allowlist	✅ Sì	Config inesistente → eccezione che bloccava il flusso
IsRegistrationEnabledAction.php	Stessa cosa, rimosso Assert::boolean	✅ Sì	Stessa causa — config inesistente → eccezione
RedirectToLoginAction.php	Gestione array nella traduzione	✅ Sì	__('user::auth.login-failed') restituisce array → Assert::string esplodeva
LoginUserAction.php	session()->regenerate()	⚠️ Miglioramento	Era commentato nell'originale — aggiunge sicurezza (session fixation) ma non era indispensabile
LoginUserAction.php	redirect('/') → redirect('/'.locale)`	⚠️ Miglioramento	Il middleware locale gestiva già / → /it, ma essere espliciti è più corretto

Conclusione: 7 modifiche su 9 erano bug reali che producevano eccezioni durante il flusso OAuth. Le 2 modifiche in LoginUserAction sono miglioramenti, non fix obbligatori.

[Malebestia]

Nota aperta — le due route FO/BO fanno la stessa cosa oggi

Le route /auth/social/{provider} (FO) e /admin/login/{provider} (BO) puntano entrambe a RedirectToProviderController (stesso controller, nessun middleware), e la callback condivisa /sso/{provider}/callback redirige sempre a /it. Non c'è logica che differenzia FO da BO nel controller.

Perché sono distinte:

1. URL semantica — /admin/login/google è fuorviante per un cittadino
2. Anticipano STORY-461: quando arriverà il login BO operatori, la callback dovrà distinguere FO da BO per redirigere diversamente (/it vs /admin/dashboard)

Alternativa DRY: il bottone FO potrebbe puntare direttamente a /admin/login/{provider} — funzionerebbe ugualmente oggi. Il problema FO/BO si affronterebbe alla callback quando arriva STORY-461.

Decisione aperta — da prendere prima o durante STORY-461.