Proteggere un'app autonoma ASP.NET Core Blazor WebAssembly con la libreria di autenticazione

Questo articolo illustra come proteggere un'app autonoma ASP.NET Core Blazor WebAssembly con la libreria di autenticazione Blazor WebAssembly.

La libreria di autenticazione Blazor WebAssembly (Authentication.js) supporta solo il flusso del codice di autorizzazione proof key for Code Exchange (PKCE) tramite l'Libreria di Autenticazione Microsoft (MSAL, msal.js). Per implementare altri flussi di concessione, accedere alle linee guida di MSAL per implementare direttamente MSAL, ma non supportiamo né consigliamo l'uso di flussi di concessione diversi da PKCE per le applicazioni Blazor.

Per indicazioni su Microsoft Entra (ME-ID), non seguire le indicazioni riportate in questo argomento. Vedere Proteggere un'app autonoma ASP.NET Core Blazor WebAssembly con Microsoft Entra ID.

Per altre informazioni sullo scenario di sicurezza dopo aver letto questo articolo, vedere ASP.NET Core Blazor WebAssembly scenari di sicurezza aggiuntivi.

Walkthrough

Le sottosezioni della procedura dettagliata illustrano come:

• Registrare un'app
• Creare l'app Blazor
• Eseguire l'app

Registrare un'app

Registrare un'app con un provider OIDC (OpenID Connect)Identity seguendo le indicazioni fornite dal gestore dell'INDIRIZZO IP.

Registrare le informazioni seguenti:

• Autorità (ad esempio, https://accounts.google.com/).
• ID applicazione (client) (ad esempio, 2...7-e...q.apps.googleusercontent.com).
• Configurazione IP aggiuntiva (vedere la documentazione dell'INDIRIZZO IP).

Creare l'app Blazor

Per creare un'app autonoma Blazor WebAssembly che usa la libreria Microsoft.AspNetCore.Components.WebAssembly.Authentication, seguire le indicazioni per la scelta degli strumenti. Se si aggiunge il supporto per l'autenticazione, vedere la sezione Parti dell'app di questo articolo per indicazioni sulla configurazione e la configurazione dell'app.

dotnet new blazorwasm -au Individual -o {PROJECT NAME}

Configurare l'app

Configurare l'app seguendo le indicazioni fornite dall'IP. Al minimo, l'app richiede le impostazioni di configurazione Local:Authority e Local:ClientId nel file wwwroot/appsettings.json dell'app.

{
  "Local": {
    "Authority": "{AUTHORITY}",
    "ClientId": "{CLIENT ID}"
  }
}

Esempio OIDC di Google OAuth 2.0 per un'app eseguita sull'indirizzo localhost sulla porta 5001:

{
  "Local": {
    "Authority": "https://accounts.google.com/",
    "ClientId": "2...7-e...q.apps.googleusercontent.com",
    "PostLogoutRedirectUri": "https://localhost:5001/authentication/logout-callback",
    "RedirectUri": "https://localhost:5001/authentication/login-callback",
    "ResponseType": "code"
  }
}

L'URI di reindirizzamento (https://localhost:5001/authentication/login-callback) è registrato nella Google APIs Console sotto Credenziali>{NAME}>URI di reindirizzamento autorizzati, dove {NAME} è il nome del client dell'app nell'elenco ID Client OAuth 2.0 della console delle API Google.

Eseguire l'app

Usare uno degli approcci seguenti per eseguire l'app:

• Visual Studio
  • Selezionare il pulsante Run (Esegui).
  • Usare Debug>Avvia debug dal menu.
  • Premere F5.
• Interfaccia della riga di comando .NET: eseguire il comando dotnet watch (o dotnet run) dalla cartella dell'app.

Percorsi di autenticazione remota

I percorsi di autenticazione remota vengono personalizzati usando RemoteAuthenticationApplicationPathsOptions su RemoteAuthenticationOptions<TRemoteAuthenticationProviderOptions>.AuthenticationPaths nel file Program dell'app. Per i valori di percorso predefiniti del framework, vedere la fonte didotnet/aspnetcore riferimento.

Se un'app personalizza un percorso di autenticazione remota, adottare uno degli approcci seguenti:

• Abbina il percorso nelle stringhe codificate in modo fisso all'interno dell'app.

• Inserire Microsoft.AspNetCore.Components.WebAssembly.Authentication.RemoteAuthenticationOptions<TRemoteAuthenticationProviderOptions> per ottenere il valore configurato intorno all'app. Nell'esempio seguente viene illustrato l'approccio per il RedirectToLogin componente.

  Aggiungere le seguenti direttive Razor all'inizio del file del componente Razor.

  @using Microsoft.Extensions.Options
  @inject IOptionsSnapshot<RemoteAuthenticationOptions<ApiAuthorizationProviderOptions>> RemoteOptions
  

  Modificare il reindirizzamento del componente nel metodo OnInitialized.

  - Navigation.NavigateToLogin("authentication/login");
  + Navigation.NavigateToLogin(RemoteOptions.Get(Options.DefaultName)
  +     .AuthenticationPaths.LogInPath);
  

  Note

  Se gli altri percorsi differiscono dai percorsi del modello di progetto o dai percorsi predefiniti del framework, gestirli nello stesso modo.

Parti dell'app

Questa sezione descrive le parti di un'app generata dal Blazor WebAssembly modello di progetto e la modalità di configurazione dell'app. Non sono disponibili indicazioni specifiche da seguire in questa sezione per un'applicazione funzionante di base se è stata creata l'app usando le indicazioni nella sezione Procedura dettagliata . Le indicazioni contenute in questa sezione sono utili per aggiornare un'app per autenticare e autorizzare gli utenti. Tuttavia, un approccio alternativo all'aggiornamento di un'app consiste nel creare una nuova app dalle indicazioni nella sezione Procedura dettagliata e spostare i componenti, le classi e le risorse dell'app nella nuova app.

Pacchetto di autenticazione

Quando un'app viene creata per usare account singoli, l'app riceve automaticamente un riferimento al pacchetto per il pacchetto Microsoft.AspNetCore.Components.WebAssembly.Authentication. Il pacchetto fornisce un set di primitive che consentono all'app di autenticare gli utenti e ottenere i token per chiamare le API protette.

Se si aggiunge l'autenticazione a un'app, aggiungere manualmente il pacchetto Microsoft.AspNetCore.Components.WebAssembly.Authentication all'app.

Supporto del servizio di autenticazione

Il supporto per l'autenticazione degli utenti che usano OpenID Connect (OIDC) viene registrato nel contenitore del servizio con il metodo di estensione AddOidcAuthentication fornito dal pacchetto Microsoft.AspNetCore.Components.WebAssembly.Authentication.

Il AddOidcAuthentication metodo accetta un callback per configurare i parametri necessari per autenticare un'app usando OIDC. I valori necessari per la configurazione dell'app possono essere ottenuti dall'INDIRIZZO IP conforme a OIDC. Ottieni i valori quando registri l'app, cosa che generalmente avviene nel loro portale online.

Per una nuova app, specificare i valori per i {AUTHORITY} segnaposto e {CLIENT ID} nella configurazione seguente. Specificare altri valori di configurazione necessari per l'uso con l'indirizzo IP dell'app. L'esempio è per Google, che richiede PostLogoutRedirectUri, RedirectUrie ResponseType. Se si aggiunge l'autenticazione a un'app, aggiungere manualmente il codice e la configurazione seguenti all'app con valori per i segnaposto e altri valori di configurazione.

Nel file Program:

builder.Services.AddOidcAuthentication(options =>
{
    builder.Configuration.Bind("Local", options.ProviderOptions);
});

Configurazione wwwroot/appsettings.json

La configurazione viene fornita dal wwwroot/appsettings.json file :

{
  "Local": {
    "Authority": "{AUTHORITY}",
    "ClientId": "{CLIENT ID}"
  }
}

Ambiti del token di accesso

Il Blazor WebAssembly modello configura automaticamente gli ambiti predefiniti per openid e profile.

Il Blazor WebAssembly modello non configura automaticamente l'app per richiedere un token di accesso per un'API sicura. Per fornire un token di accesso come parte del processo di autentificazione, aggiungere lo scopo agli scopi di token predefiniti di OidcProviderOptions. Se si aggiunge l'autenticazione a un'app, aggiungere manualmente il codice seguente e configurare l'URI dell'ambito.

Nel file Program:

builder.Services.AddOidcAuthentication(options =>
{
    ...
    options.ProviderOptions.DefaultScopes.Add("{SCOPE URI}");
});

Per altre informazioni, vedere le sezioni seguenti dell'articolo Scenari aggiuntivi :

• Richiedere token di accesso aggiuntivi
• Collegare i token alle richieste in uscita

Importa il file

Lo spazio dei nomi Microsoft.AspNetCore.Components.Authorization viene reso disponibile in tutta l'app tramite il file _Imports.razor:

...
@using Microsoft.AspNetCore.Components.Authorization
...

Pagina Indice

La pagina Indice (wwwroot/index.html) include uno script che definisce il AuthenticationService in JavaScript. AuthenticationService gestisce i dettagli di basso livello del protocollo OIDC. L'app chiama internamente i metodi definiti nello script per eseguire le operazioni di autenticazione.

<script src="_content/Microsoft.AspNetCore.Components.WebAssembly.Authentication/AuthenticationService.js"></script>

Componente dell'app

Il App componente (App.razor) è simile al App componente presente nelle Blazor Server app:

A causa delle modifiche apportate al framework nelle versioni di ASP.NET Core, Razor markup per il componente App (App.razor) non viene visualizzato in questa sezione. Per esaminare il markup del componente per una determinata versione, usare uno degli approcci seguenti:

• Creare un'app di cui è stato effettuato il provisioning per l'autenticazione dal modello di progetto Blazor WebAssembly predefinito per la versione di ASP.NET Core che si intende usare. Esaminare il componente App (App.razor) nell'app generata.

• Esaminare il componente App (App.razor) nell'origine di riferimento. Selezionare la versione dal selettore di ramo e cercare il componente nella ProjectTemplates cartella del repository perché è stato spostato nel corso degli anni.

  Note

  I collegamenti alla documentazione della sorgente di riferimento .NET in genere caricano il branch predefinito del repository, che rappresenta lo sviluppo in corso della versione successiva di .NET. Per selezionare un tag per una versione specifica, usare l'elenco a discesa Switch branches or tags. Per altre informazioni, vedere Come selezionare un tag di versione del codice sorgente ASP.NET Core (dotnet/AspNetCore.Docs #26205).

Componente RedirectToLogin

Componente RedirectToLogin (RedirectToLogin.razor):

• Gestisce il reindirizzamento di utenti non autorizzati alla pagina di accesso.
• L'URL corrente a cui l'utente sta tentando di accedere viene mantenuto in modo che possa essere restituito a tale pagina se l'autenticazione ha esito positivo:
  • Stato della cronologia di esplorazione in ASP.NET Core in .NET 7 o versione successiva.
  • Stringa di query in ASP.NET Core nella versione di .NET 6 o precedenti.

Esaminare il componente RedirectToLogin nelle origini di riferimento. La posizione del componente è cambiata nel tempo, quindi usare GitHub strumenti di ricerca per individuare il componente.

Componente LoginDisplay

Il componente LoginDisplay (LoginDisplay.razor) viene renderizzato nel componente MainLayout (MainLayout.razor) e gestisce i seguenti comportamenti:

• Per gli utenti autenticati:
  • Visualizza il nome utente corrente.
  • Offre un collegamento alla pagina del profilo utente in ASP.NET Core Identity.
  • Offre un pulsante per disconnettersi dall'app.
• Per gli utenti anonimi:
  • Offre la possibilità di registrarsi.
  • Offre l'opzione di effettuare l'accesso.

A causa delle modifiche apportate al framework tra versioni di ASP.NET Core, Razor markup per il componente LoginDisplay non viene visualizzato in questa sezione. Per esaminare il markup del componente per una determinata versione, usare uno degli approcci seguenti:

• Creare un'app di cui è stato effettuato il provisioning per l'autenticazione dal modello di progetto Blazor WebAssembly predefinito per la versione di ASP.NET Core che si intende usare. Ispeziona il componente LoginDisplay nell'app generata.

• Esaminare il componente LoginDisplay nelle origini di riferimento. La posizione del componente è cambiata nel tempo, quindi usare GitHub strumenti di ricerca per individuare il componente. Viene utilizzato il contenuto modulare per Hosted, uguale a true.

  Note

  I collegamenti alla documentazione della sorgente di riferimento .NET in genere caricano il branch predefinito del repository, che rappresenta lo sviluppo in corso della versione successiva di .NET. Per selezionare un tag per una versione specifica, usare l'elenco a discesa Switch branches or tags. Per altre informazioni, vedere Come selezionare un tag di versione del codice sorgente ASP.NET Core (dotnet/AspNetCore.Docs #26205).

Componente di autenticazione

La pagina prodotta dal Authentication componente (Pages/Authentication.razor) definisce le route necessarie per la gestione di diverse fasi di autenticazione.

Componente RemoteAuthenticatorView :

• Viene fornito dal pacchetto Microsoft.AspNetCore.Components.WebAssembly.Authentication.
• Gestisce l'esecuzione delle azioni appropriate in ogni fase di autenticazione.

@page "/authentication/{action}"
@using Microsoft.AspNetCore.Components.WebAssembly.Authentication

<RemoteAuthenticatorView Action="@Action" />

@code {
    [Parameter]
    public string? Action { get; set; }
}

Troubleshoot

Logging

Per abilitare il logging di debug o trace per l'autenticazione Blazor WebAssembly, vedere la sezione Registrazione dell'autenticazione lato client nella parte di ASP.NET Core Blazor logging con il selettore della versione dell'articolo impostato su ASP.NET Core in .NET 7 o versione successiva.

Errori comuni

• Configurazione errata dell'app o Identity del provider (IP)

  Gli errori più comuni sono causati da una configurazione errata. Di seguito sono riportati alcuni esempi:

  • A seconda dei requisiti dello scenario, un'autorità mancante o non corretta, istanza, ID tenant, dominio tenant, ID client o URI di reindirizzamento impedisce a un'app di autenticare i client.
  • Gli ambiti di richiesta non corretti impediscono ai client di accedere agli endpoint DELL'API Web del server.
  • Autorizzazioni DELL'API server non corrette o mancanti impediscono ai client di accedere agli endpoint DELL'API Web del server.
  • L'esecuzione dell'app in una porta diversa da quella configurata nell'URI di reindirizzamento della registrazione dell'app ip. Si noti che una porta non è necessaria per Microsoft Entra ID e un'app in esecuzione in un indirizzo di test di sviluppo localhost, ma la configurazione della porta dell'app e la porta su cui l'app è in esecuzione devono corrispondere per indirizzi diversi da localhost.

  Le sezioni di configurazione di questo articolo illustrano esempi della configurazione corretta. Controllare attentamente ogni sezione dell'articolo alla ricerca di errori di configurazione di app e IP.

  Se la configurazione è corretta:

  • Analizzare i log delle applicazioni.

  • Esaminare il traffico di rete tra l'app client e l'app IP o server con gli strumenti di sviluppo del browser. Spesso, un messaggio di errore esatto o un messaggio con un indizio sulla causa del problema viene restituito al client dall'app IP o server dopo aver effettuato una richiesta. Il supporto per strumenti per sviluppatori si trova negli articoli seguenti:

    • Google Chrome (documentazione di Google)
    • Microsoft Edge
    • Mozilla Firefox (documentazione di Mozilla)

  • Per le versioni in Blazor cui si utilizza un token JSON Web (JWT), decodificare i contenuti del token usato per autenticare un client o accedere a un'API Web del server, a seconda di dove si verifica il problema. Per altre informazioni, vedere Esaminare il contenuto di un token JSON Web (JWT).

  Il team della documentazione risponde al feedback e ai bug dei documenti negli articoli (aprire un problema dalla sezione Commenti e suggerimenti della pagina ), ma non è in grado di fornire supporto tecnico. Sono disponibili diversi forum di supporto pubblico per facilitare la risoluzione dei problemi di un'app. Consigliamo quanto segue:

  • Stack Overflow (tag: blazor)
  • ASP.NET Core Slack Team
  • Blazor Gitter

  I forum precedenti non sono di proprietà o controllati da Microsoft.

  Per i report sui bug del framework non riservati, non sensibili e non confidenziali, aprire un problema con il team di prodotto ASP.NET Core. Non aprire un problema con l'unità di prodotto fino a quando non hai approfondito la causa di un problema e non puoi risolverlo autonomamente e con l'aiuto della community in un forum di supporto pubblico. L'unità prodotto non è in grado di risolvere i problemi relativi alle singole app interrotte a causa di semplici errori di configurazione o casi d'uso che coinvolgono servizi di terze parti. Se un report è sensibile o riservato per natura o descrive un potenziale difetto di sicurezza nel prodotto che possono sfruttare i cyberattaccanti, consultare Reporting dei problemi di sicurezza e dei bug (repository dotnet/aspnetcore GitHub).

• Client non autorizzato per ME-ID

  info: Microsoft.AspNetCore.Authorization.DefaultAuthorizationService[2] L'autorizzazione è fallita. Questi requisiti non sono stati soddisfatti: DenyAnonymousAuthorizationRequirement: richiede un utente autenticato.

  Errore di callback di accesso da ME-ID:

  • Errore: unauthorized_client
  • Description (Descrizione): AADB2C90058: The provided application is not configured to allow public clients.

  Per risolvere l'errore:

  1. Nel portale di Azure accedere al manifesto di app.
  2. Impostare l'attributo allowPublicClient su null o .true

Cookie e dati del sito

I cookie e i dati del sito possono persistere tra gli aggiornamenti delle app e interferire con i test e la risoluzione dei problemi. Cancellare quanto segue quando si apportano modifiche al codice dell'app, modifiche all'account utente con il provider o modifiche alla configurazione dell'app del provider:

• Cookie di accesso utente
• Cookie dell'app
• Dati del sito memorizzati nella cache e archiviati

Un approccio per evitare che i cookie e i dati del sito persistenti interferiscano con i test e la risoluzione dei problemi consiste nel:

• Configurare un browser
  • Usa un browser per i test che puoi configurare per eliminare tutti i dati cookie e del sito ogni volta che il browser viene chiuso.
  • Assicurarsi che il browser venga chiuso manualmente o dall'IDE per qualsiasi modifica apportata alla configurazione dell'app, dell'utente di test o del provider.
• Usare un comando personalizzato per aprire un browser in modalità InPrivate o In incognito in Visual Studio:
  • Aprire la finestra di dialogo Browse With dal pulsante Run1 di Visual Studio.
  • Seleziona il pulsante Aggiungi.
  • Specificare il percorso del browser nel campo Programma . I percorsi eseguibili seguenti sono percorsi di installazione tipici per Windows 10. Se il browser è installato in un percorso diverso o non si usa Windows 10, specificare il percorso dell'eseguibile del browser.
    • Microsoft Edge: C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe
    • Google Chrome: C:\Program Files (x86)\Google\Chrome\Application\chrome.exe
    • Mozilla Firefox: C:\Program Files\Mozilla Firefox\firefox.exe
  • Nel campo Argomenti specificare l'opzione della riga di comando usata dal browser per aprire in modalità InPrivate o Incognito. Alcuni browser richiedono l'URL dell'app.
    • Microsoft Edge: usare -inprivate.
    • Google Chrome: usare --incognito --new-window {URL}, dove il {URL} segnaposto è l'URL da aprire (ad esempio, https://localhost:5001).
    • Mozilla Firefox: usare -private -url {URL}, dove il {URL} segnaposto è l'URL da aprire (ad esempio, https://localhost:5001).
  • Specificare un nome nel campo Nome descrittivo. Ad esempio: Firefox Auth Testing.
  • Selezionare il pulsante OK.
  • Per evitare di dover selezionare il profilo del browser per ogni iterazione di test con un'app, impostare il profilo come predefinito con il pulsante Imposta come predefinito .
  • Assicurarsi che il browser sia chiuso dall'IDE per qualsiasi modifica apportata all'app, all'utente di test o alla configurazione del provider.

Aggiornamenti delle app

Un'app funzionante potrebbe non funzionare più dopo l'aggiornamento del .NET SDK sulla macchina di sviluppo o la modifica delle versioni dei pacchetti all'interno dell'app. In alcuni casi i pacchetti incoerenti possono interrompere un'app quando si eseguono aggiornamenti principali. La maggior parte di questi problemi può essere risolta attenendosi alle istruzioni seguenti:

1. Cancellare le cache dei pacchetti NuGet del sistema locale eseguendo dotnet nuget locals all --clear da una shell dei comandi.
2. Eliminare le cartelle e bin del obj progetto.
3. Ripristinare e ricompilare il progetto.
4. Eliminare tutti i file nella cartella di distribuzione nel server prima di ridistribuire l'app.

Esaminare l'utente

Il componente seguente User può essere usato direttamente nelle app o funge da base per un'ulteriore personalizzazione.

User.razor:

@page "/user"
@attribute [Authorize]
@using System.Text.Json
@using System.Security.Claims
@inject IAccessTokenProvider AuthorizationService

<h1>@AuthenticatedUser?.Identity?.Name</h1>

<h2>Claims</h2>

@foreach (var claim in AuthenticatedUser?.Claims ?? Array.Empty<Claim>())
{
    <p class="claim">@(claim.Type): @claim.Value</p>
}

<h2>Access token</h2>

<p id="access-token">@AccessToken?.Value</p>

<h2>Access token claims</h2>

@foreach (var claim in GetAccessTokenClaims())
{
    <p>@(claim.Key): @claim.Value.ToString()</p>
}

@if (AccessToken != null)
{
    <h2>Access token expires</h2>

    <p>Current time: <span id="current-time">@DateTimeOffset.Now</span></p>
    <p id="access-token-expires">@AccessToken.Expires</p>

    <h2>Access token granted scopes (as reported by the API)</h2>

    @foreach (var scope in AccessToken.GrantedScopes)
    {
        <p>Scope: @scope</p>
    }
}

@code {
    [CascadingParameter]
    private Task<AuthenticationState> AuthenticationState { get; set; }

    public ClaimsPrincipal AuthenticatedUser { get; set; }
    public AccessToken AccessToken { get; set; }

    protected override async Task OnInitializedAsync()
    {
        await base.OnInitializedAsync();
        var state = await AuthenticationState;
        var accessTokenResult = await AuthorizationService.RequestAccessToken();

        if (!accessTokenResult.TryGetToken(out var token))
        {
            throw new InvalidOperationException(
                "Failed to provision the access token.");
        }

        AccessToken = token;

        AuthenticatedUser = state.User;
    }

    protected IDictionary<string, object> GetAccessTokenClaims()
    {
        if (AccessToken == null)
        {
            return new Dictionary<string, object>();
        }

        // header.payload.signature
        var payload = AccessToken.Value.Split(".")[1];
        var base64Payload = payload.Replace('-', '+').Replace('_', '/')
            .PadRight(payload.Length + (4 - payload.Length % 4) % 4, '=');

        return JsonSerializer.Deserialize<IDictionary<string, object>>(
            Convert.FromBase64String(base64Payload));
    }
}

Esaminare il contenuto di un token JSON Web (JWT)

Per decodificare un token JSON Web (JWT), utilizzare lo strumento jwt.ms di Microsoft. I valori nell'interfaccia utente non lasciano mai il browser.

JWT codificato di esempio (abbreviato per la visualizzazione):

eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6Ilg1ZVhrNHh5b2pORnVtMWtsMll0djhkbE5QNC1j ... bQdHBHGcQQRbW7Wmo6SWYG4V_bU55Ug_PW4pLPr20tTS8Ct7_uwy9DWrzCMzpD-EiwT5IjXwlGX3IXVjHIlX50IVIydBoPQtadvT7saKo1G5Jmutgq41o-dmz6-yBMKV2_nXA25Q

Esempio JWT decodificato dallo strumento per un'app che esegue l'autenticazione in Azure AAD B2C:

{
  "typ": "JWT",
  "alg": "RS256",
  "kid": "X5eXk4xyojNFum1kl2Ytv8dlNP4-c57dO6QGTVBwaNk"
}.{
  "exp": 1610059429,
  "nbf": 1610055829,
  "ver": "1.0",
  "iss": "https://mysiteb2c.b2clogin.com/11112222-bbbb-3333-cccc-4444dddd5555/v2.0/",
  "sub": "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb",
  "aud": "00001111-aaaa-2222-bbbb-3333cccc4444",
  "nonce": "bbbb0000-cccc-1111-dddd-2222eeee3333",
  "iat": 1610055829,
  "auth_time": 1610055822,
  "idp": "idp.com",
  "tfp": "B2C_1_signupsignin"
}.[Signature]

Risorse aggiuntive

• ASP.NET Core Blazor WebAssembly scenari di sicurezza aggiuntivi
• Richieste API Web non autenticate o non autorizzate in un'app con un client predefinito sicuro
• Configurare ASP.NET Core per l'uso con server proxy e servizi di bilanciamento del carico: include indicazioni su:
  • Utilizzo del middleware per le intestazioni inoltrate per mantenere le informazioni sul protocollo HTTPS tra server proxy e reti interne.
  • Altri scenari e casi d'uso, tra cui la configurazione manuale dello schema, le modifiche del percorso della richiesta per il routing corretto delle richieste e l'inoltro dello schema delle richieste per i proxy inversi Linux e non IIS.