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
Configurare e gestire sidecar container in Azure App Service
Generare HTML a runtime a partire da un componente Razor in ASP.NET Core
Path addizionali per gli asset in ASP.NET Core MVC
Rendere le variabili read-only in una pipeline di Azure DevOps
Creare una libreria CSS universale: Nav menu
Documentare i servizi REST con Swagger e OpenAPI con .NET 9
Utilizzare Azure AI Studio per testare i modelli AI
Potenziare la ricerca su Cosmos DB con Full Text Search
La gestione della riconnessione al server di Blazor in .NET 9
Sfruttare GPT-4o realtime su Azure Open AI per conversazioni vocali
Recuperare l'ultima versione di una release di GitHub