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
Generare HTML a runtime a partire da un componente Razor in ASP.NET Core
Registrare servizi multipli tramite chiavi in ASP.NET Core 8
Creare una libreria CSS universale: Cards
Gestire il colore CSS con HWB
Utilizzare Azure Cosmos DB con i vettori
Utilizzare EF.Constant per evitare la parametrizzazione di query SQL
Usare un KeyedService di default in ASP.NET Core 8
Eseguire le GitHub Actions offline
Eseguire un metodo asincrono dopo il set di una proprietà in Blazor 8
Effettuare il log delle chiamate a function di GPT in ASP.NET Web API
Gestire la cancellazione di una richiesta in streaming da Blazor
I più letti di oggi
- Effettuare il log delle chiamate a function di GPT in ASP.NET Web API
- ecco tutte le novità pubblicate sui nostri siti questa settimana: https://aspit.co/wkly buon week-end!
- Utilizzare il metodo CountBy di LINQ per semplificare raggruppamenti e i conteggi
- Creare una libreria CSS universale: Cards
- Eseguire script pre e post esecuzione di un workflow di GitHub