Nello script precedente (http://aspit.co/a2d) abbiamo iniziato ad analizzare le modalità per configurare l'autenticazione basata su cookie in ASP.NET Identity. Come abbiamo già accennato, tutto avviene tramite un metodo contenuto all'interno del file Startup.Auth.cs:
app.UseCookieAuthentication(new CookieAuthenticationOptions { AuthenticationType = DefaultAuthenticationTypes.ApplicationCookie, LoginPath = new PathString("/Account/Login"), Provider = new CookieAuthenticationProvider { OnValidateIdentity = SecurityStampValidator .OnValidateIdentity<ApplicationUserManager, ApplicationUser>( validateInterval: TimeSpan.FromMinutes(30), regenerateIdentity: (manager, user) => user.GenerateUserIdentityAsync(manager)) } });
Cerchiamo di capire quali siano le altre possibilità di manovra che abbiamo.
Sfruttare l'estendibilità di ASP.NET Identity
- Provider è la proprietà da valorizzare con un'istanza di ICookieAuthenticationProvider se vogliamo intervenire sulle proprietà del cookie nel momento in cui viene emesso, oppure, di eseguire logica personalizzata all'atto della sua conseguente validazione. Nel template di Visual Studio 2013, troviamo questa proprietà valorizzata con un CookieAuthenticationProvider che sfrutta il SecurityStampValidator per consentire il sign-out remoto di un utente, di cui abbiamo parlato in un precedente script (http://aspit.co/a11).
- SystemClock accetta un ISystemClock che ha il solo scopo di restituire la data/ora UTC corrente. ASP.NET Identity è costruito per essere debolmente accoppiato ad ogni altro componente esterno (il clock di sistema, in questo caso). Questo lo rende estremamente testabile infatti, in ambito di unit testing, con una nostra implementazione di ISystemClock potremmo facilmente simulare il passaggio del tempo e la conseguente scadenza del cookie.
- TicketDataFormat può essere valorizzato con un ISecureDataFormat
per personalizzare la cifratura (e decifratura) del contenuto del cookie. In questo modo siamo potenzialmente in grado di intepretare i cookie emessi da un'altra applicazione, anche non ASP.NET, che usi un proprio algoritmo di crittografia.
Modificare gli attributi del cookie
- CookieDomain indica il dominio di validità del cookie. Tipicamente, un cookie è valido solo all'interno del dominio per il quale è stato emesso ma, se volessimo estenderne la validità ad altri sottodomini che ospitano altre nostre applicazioni, allora potremmo valorizzarlo con la stringa ".nomedominio.ext"
- CookiePath accetta un percorso virtuale, come ad esempio "/App1", usato per restringere la validità del cookie ad una data sottocartella. Utile quando ospitiamo più applicazioni nello stesso dominio, e vogliamo tenere isolati i rispettivi meccanismi di autenticazione.
- CookieHttpOnly di default impostato a true, impedisce che il cookie sia accessibile lato client, per mezzo di codice javascript.
- CookieName contiene il nome con il quale il browser salverà il cookie. Modificare il nome mentre l'applicazione è in produzione vuol dire ignorare tutti i cookie di autenticazione emessi in precedenza e costringere gli utenti ad effettuare di nuovo l'accesso.
- CookieSecure può restringere la validità del cookie alle sole pagine protette da HTTPS. Il valore di default è invece CookieSecureOption.SameAsRequest, che è un'opzione molto versatile perché consente l'emissione del cookie sia quando siamo in fase di sviluppo (su HTTP) che in produzione (idealmente su HTTPS).
Un'ultima nota relativa alla configurazione: come abbiamo visto, usando ASP.NET Identity, la configurazione si sposta dal tradizionale web.config ad un oggetto CookieAuthenticationOptions di cui valorizziamo le proprietà.
Questo potrebbe suggerirci che, ad ogni piccola modifica della configurazione, sia necessario ricompilare e ridistribuire l'applicazione. In realtà, siamo liberi di continuare ad usare il web.config e di leggere le impostazioni da chiavi appSettings predisposte allo scopo. Se lo preferiamo, possiamo scrivere un'apposita configSection personalizzata, in modo da lavorare con un oggetto di configurazione che permette l'accesso ai valori in maniera fortemente tipizzata.
Commenti
Per inserire un commento, devi avere un account.
Fai il login e torna a questa pagina, oppure registrati alla nostra community.
Approfondimenti
Gestire liste di tipi semplici con Entity Framework Core
Utilizzare QuickGrid di Blazor con Entity Framework
Ottimizzare la latenza in Blazor 8 tramite InteractiveAuto render mode
Configurare policy CORS in Azure Container Apps
Eseguire un metodo asincrono dopo il set di una proprietà in Blazor 8
Eseguire query manipolando le liste contenute in un oggetto mappato verso una colonna JSON
Verificare la provenienza di un commit tramite le GitHub Actions
Usare una container image come runner di GitHub Actions
Creare gruppi di client per Event Grid MQTT
Utilizzare la session affinity con Azure Container Apps
Utilizzare Tailwind CSS all'interno di React: primi componenti
Registrare servizi multipli tramite chiavi in ASP.NET Core 8
I più letti di oggi
- Utilizzare Docker Compose con Azure App Service
- Modernizzare le applicazioni WPF e Windows Forms con Blazor
- annunciato #netstandard 2.1. .NET Core lo supporterà a partire da #netcore3, così come le prossime versione di #xamarin, #mono e #unity.il supporto per #netfx 4.8, invece, non ci sarà. https://aspit.co/bq2
- Steel Style CheckBox per Silverlight 4.0
- Utilizzare QuickGrid di Blazor con Entity Framework