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
Supporto ai tipi DateOnly e TimeOnly in Entity Framework Core
Recuperare automaticamente un utente e aggiungerlo ad un gruppo di Azure DevOps
Conoscere il rendering Server o WebAssembly a runtime in Blazor
Evitare il flickering dei componenti nel prerender di Blazor 8
Eseguire query manipolando le liste contenute in un oggetto mappato verso una colonna JSON
Inference di dati strutturati da testo con Semantic Kernel e ASP.NET Core Web API
Aprire una finestra di dialogo per selezionare una directory in WPF e .NET 8
Gestire eccezioni nei plugin di Semantic Kernel in ASP.NET Core Web API
Supportare la sessione affinity di Azure App Service con Application Gateway
Utilizzare una qualunque lista per i parametri di tipo params in C#
Gestione degli stili CSS con le regole @layer