Spesso, durante lo sviluppo del nostro sito web ASP.NET Core, o del nostro progetto Web API, abbiamo la necessità di impostare un utente fittizio per ragioni di test. Solitamente questo accade quando lo stack di autenticazione è ancora da sviluppare o da integrare, ma comunque vogliamo verificare che la logica di autorizzazione che regola l'accesso ai nostri controller sia corretta.
Il modo migliore per farlo è creare un ClaimsPrincipal durante le fasi iniziali della richiesta, così che il resto della logica possa rimanere invariata. Un custom middleware da configurare nella classe Startup, pertanto, è esattamente ciò che fa al caso nostro:
public void Configure(IApplicationBuilder app, IHostingEnvironment env) { if (env.IsDevelopment()) { app.UseDeveloperExceptionPage(); app.UseDatabaseErrorPage(); app.Use(async (context, next) => { var claims = new List<Claim>() { new Claim(ClaimTypes.Name, "testUser"), new Claim(ClaimTypes.Role, "Admin") }; var scheme = IdentityConstants.ApplicationScheme; var identity = new ClaimsIdentity(claims, scheme); var principal = new ClaimsPrincipal(identity); context.User = principal; await next(); }); } // .. altro codice qui .. }
Il codice in alto è abbastanza intuitivo. Innanzi tutto, è importante segnalare come il codice venga eseguito solo quando si è in modalità "Development", così che non rischiamo di lasciare aperto un evidente buco di sicurezza una volta che l'applicazione sia stata rilasciata.
Il nostro middleware costruisce innanzi tutto una collezione di Claim per l'utente. Nell'esempio in alto abbiamo impostato Name e Role, ma ovviamente possiamo personalizzare questa collection a piacimento, così da poter testare scenari autorizzativi più complessi.
Il passo successivo è costruire un oggetto ClaimsIdentity. Qui l'aspetto importante da specificare è lo schema di autenticazione. ASP.NET Core, infatti, supporta diversi schema (https://docs.microsoft.com/en-us/aspnet/core/security/authorization/limitingidentitybyscheme), per gestire diverse tecniche di autenticazione contemporaneamente ed è importante che questa variabile sia la medesima della tecnologia che andremo a usare.
Per esempio, nel caso di ASP.NET Identity, lo schema è IdentityConstants.ApplicationScheme, mentre se stessimo usando autenticazione basata su Jwt Token in Web API, avremmo dovuto usare
JwtBearerDefaults.AuthenticationScheme
A questo punto non dobbiamo far altro che costruire il ClaimsPrincipal a partire dall'identity appena creata e impostarlo come utente corrente nel context della richiesta, per poi invocare il prossimo middleware e proseguire l'elaborazione della richiesta.
Commenti
Per inserire un commento, devi avere un account.
Fai il login e torna a questa pagina, oppure registrati alla nostra community.
Approfondimenti
Scenari complessi di validazione con FluentValidation su ASP.NET Core
Autenticazione con JWT Token e ASP.NET Core Web API
Usare LibMan per gestire le dipendenze client in ASP.NET Core
Mostrare lo stato dei contatti con la Universal Windows Platform
Anteprima di ASP.NET Core 2.1 - Parte 2
Proteggersi dagli attacchi di Open Redirect in ASP.NET Core MVC
Creare un template riutilizzabile tramite una function in ASP.NET Core MVC
Creare una console application con la Universal Windows Platform
Usare IP Filtering per regolare l'accesso a una applicazione ASP.NET Core
Sfruttare la dependency injection in un Filter di ASP.NET Core
Gestire l'upload dei file in un controller Web API di ASP.NET Core 2.1
Disabilitare il tracking degli oggetti in Entity Framework Core
I più letti di oggi
- ecco tutte le novità pubblicate sui nostri siti questa settimana: http://aspit.co/wkly buon week-end!
- Utilizzare i tipi spatial con Entity Framework Core 2.2
- ecco tutte le novità pubblicate sui nostri siti questa settimana: http://aspit.co/wkly buon week-end!
- Leggere le informazioni dell'app package nella Universal Windows Platform
- Usare Bootstrap con ASP.NET MVC 4
- Rendere sicuro l'endpoint di HealthCheck in ASP.NET Core