Freigeben über

Sichern eines ASP.NET Core Blazor Web App mit Microsoft Entra-ID

  • Artikel

In diesem Artikel wird beschrieben, wie Sie ein Blazor Web App Microsoft-Plattform-Microsoft-Webpaket/identity Identityfür Microsoft Entra-ID mithilfe einer Beispiel-App sichern.

Die folgende Spezifikation wird behandelt:

  • Der Blazor Web App automatische Rendermodus wird mit globaler Interaktivität (InteractiveAuto)verwendet.
  • Das Serverprojekt ruft auf AddAuthenticationStateSerialization , um einen serverseitigen Authentifizierungsstatusanbieter hinzuzufügen, der zum Fluss des Authentifizierungsstatus an den Client verwendet PersistentComponentState wird. Der Client ruft AddAuthenticationStateDeserialization auf, um den vom Server übergebenen Authentifizierungsstatus zu deserialisieren und zu verwenden. Der Authentifizierungsstatus wird für die Lebensdauer der WebAssembly-Anwendung festgelegt.
  • Die App verwendet Microsoft Entra-ID basierend auf Microsoft Identity Webpaketen .
  • Die automatische nicht interaktive Tokenaktualisierung wird vom Framework verwaltet.
  • Die App verwendet serverseitige und clientseitige Dienstabstraktionen, um generierte Wetterdaten anzuzeigen:
    • Beim Rendern der Komponente auf dem Server zum Anzeigen von Weather Wetterdaten verwendet die Komponente den ServerWeatherForecaster server, um Wetterdaten direkt abzurufen (nicht über einen Web-API-Aufruf).
    • Wenn die Weather Komponente auf dem Client gerendert wird, verwendet die Komponente die ClientWeatherForecaster Dienstimplementierung, die eine vorkonfigurierte HttpClient (in der Datei des Clientprojekts Program ) verwendet, um einen Web-API-Aufruf der Minimal-API (/weather-forecast) des Serverprojekts für Wetterdaten durchzuführen. Der Minimale API-Endpunkt ruft die Wetterdaten aus der ServerWeatherForecaster Klasse ab und gibt sie zum Rendern durch die Komponente an den Client zurück.

Beispiel-App

Die Beispiel-App umfasst zwei Projekte:

  • BlazorWebAppEntra: Serverseitiges Projekt des Blazor Web App, das einen Beispiel Minimal API-Endpunkt für Wetterdaten enthält.
  • BlazorWebAppEntra.Client: Client-seitiges Projekt der Blazor Web App.

Greifen Sie auf Beispiel-Apps über den neuesten Versionsordner aus dem Stammverzeichnis des Repositorys mit dem folgenden Link zu. Die Projekte befinden sich im BlazorWebAppEntra Ordner für .NET 9 oder höher.

Anzeigen oder Herunterladen von Beispielcode (Vorgehensweise zum Herunterladen)

Server-seitiges Blazor Web App-Projekt (BlazorWebAppEntra)

Das BlazorWebAppEntra-Projekt ist das serverseitige Projekt des Blazor Web App.

Die Datei BlazorWebAppEntra.http kann zum Testen der Wetterdatenanforderung verwendet werden. Beachten Sie, dass das BlazorWebAppEntra-Projekt ausgeführt werden muss, um den Endpunkt zu testen, wobei der Endpunkt in der Datei hartcodiert ist. Weitere Informationen finden Sie unter Verwenden von HTTP-Dateien in Visual Studio 2022.

Client-seitiges Blazor Web App Projekt (BlazorWebAppEntra.Client)

Das BlazorWebAppEntra.Client-Projekt ist das clientseitige Projekt des Blazor Web App.

Wenn sich der Benutzer während des clientseitigen Renderings anmelden oder abmelden muss, wird ein erneutes Erneutes Laden einer vollständigen Seite initiiert.

Konfiguration

In diesem Abschnitt wird erläutert, wie Sie die Beispiel-App konfigurieren.

AddMicrosoftIdentityWebApp aus Microsoft Identity Web (Microsoft.Identity.Web NuGet-Paket, API-Dokumentation) wird vom AzureAd Abschnitt der Datei des Serverprojekts appsettings.json konfiguriert.

Verwenden Sie bei der Registrierung der App in der Entra oder Azure-Portal eine Webplattformkonfiguration mit einem Umleitungs-URI von https://localhost/signin-oidc (ein Port ist nicht erforderlich). Vergewissern Sie sich, dass ID-Token und Zugriffstoken unter impliziter Gewährung und Hybridflüsse nicht ausgewählt sind. Der OpenID Connect-Handler fordert automatisch die entsprechenden Token mithilfe des vom Autorisierungsendpunkt zurückgegebenen Codes an.

Konfigurieren der App

Geben Sie in der App-Einstellungsdatei des Serverprojekts (appsettings.json) die Abschnittskonfiguration der AzureAd App an. Rufen Sie die Anwendungs-ID (Client-ID), die Mandantendomäne (Herausgeber) und die Verzeichnis-ID (Mandant) aus der Registrierung der App in der Entra oder Azure-Portal ab:

"AzureAd": {
  "CallbackPath": "/signin-oidc",
  "ClientId": "{CLIENT ID}",
  "Domain": "{DOMAIN}",
  "Instance": "https://login.microsoftonline.com/",
  "ResponseType": "code",
  "TenantId": "{TENANT ID}"
},

Platzhalter im vorherigen Beispiel:

  • {CLIENT ID}: Die Anwendungs-ID (Client-ID).
  • {DOMAIN}: Die Domäne des Mandanten (Herausgebers).
  • {TENANT ID}: Die Verzeichnis-ID (Mandant).

Beispiel:

"AzureAd": {
  "CallbackPath": "/signin-oidc",
  "ClientId": "00001111-aaaa-2222-bbbb-3333cccc4444",
  "Domain": "contoso.onmicrosoft.com",
  "Instance": "https://login.microsoftonline.com/",
  "ResponseType": "code",
  "TenantId": "aaaabbbb-0000-cccc-1111-dddd2222eeee"
},

Der Rückrufpfad (CallbackPath) muss mit dem Umleitungs-URI (Anmelderückrufpfad) übereinstimmen, der beim Registrieren der Anwendung im Entra oder Azure-Portal konfiguriert ist. Pfade werden auf dem Blatt "Authentifizierung " der App-Registrierung konfiguriert. Der Standardwert CallbackPath ist /signin-oidc für einen registrierten Umleitungs-URI von https://localhost/signin-oidc (ein Port ist nicht erforderlich).

Warnung

Speichern Sie keine geheimen App-Schlüssel, Verbindungszeichenfolge s, Anmeldeinformationen, Kennwörter, persönliche Identifikationsnummern (PINs), privaten C#/.NET-Code oder private Schlüssel/Token im clientseitigen Code, der immer unsicher ist. In Test-/Staging- und Produktionsumgebungen sollten serverseitiger Blazor Code und Web-APIs sichere Authentifizierungsflüsse verwenden, die die Authentifizierung von Anmeldeinformationen innerhalb von Projektcode- oder Konfigurationsdateien vermeiden. Außerhalb der lokalen Entwicklungstests wird empfohlen, die Verwendung von Umgebungsvariablen zum Speichern vertraulicher Daten zu vermeiden, da Umgebungsvariablen nicht der sicherste Ansatz sind. Für lokale Entwicklungstests wird das Tool "Geheimer Manager" zum Sichern vertraulicher Daten empfohlen. Weitere Informationen finden Sie unter "Sichere Verwaltung vertraulicher Daten und Anmeldeinformationen".

Einrichten des geheimen Clientschlüssels

Erstellen Sie einen geheimen Clientschlüssel in der Entra-ID-Registrierung der App in der Entra oder Azure-Portal (Verwalten von>Zertifikaten und geheimen Geheimen geheimen>Clientschlüsseln). Verwenden Sie den Wert des neuen geheimen Schlüssels in der folgenden Anleitung.

Verwenden Sie entweder oder beide der folgenden Ansätze, um den geheimen Clientschlüssel für die App zu bereitstellen:

  • Secret Manager-Tool: Das Tool "Geheimer Manager" speichert private Daten auf dem lokalen Computer und wird nur während der lokalen Entwicklung verwendet.
  • Azure Key Vault: Sie können den geheimen Clientschlüssel in einem Schlüsseltresor für die Verwendung in einer beliebigen Umgebung speichern, einschließlich der Entwicklungsumgebung, wenn Sie lokal arbeiten. Einige Entwickler bevorzugen es, Schlüsseltresor für Staging- und Produktionsbereitstellungen zu verwenden und das Secret Manager-Tool für die lokale Entwicklung zu verwenden.

Es wird dringend empfohlen, das Speichern geheimer Clientschlüssel in Projektcode- oder Konfigurationsdateien zu vermeiden. Verwenden Sie sichere Authentifizierungsflüsse, z. B. entweder oder beide Ansätze in diesem Abschnitt.

Geheimer Manager-Tool

Das Tool "Geheimer Manager" kann den geheimen Clientschlüssel der Server-App unter dem Konfigurationsschlüssel AzureAd:ClientSecretspeichern.

Die Beispiel-App wurde für das Tool "Geheimer Manager" nicht initialisiert. Verwenden Sie eine Befehlsshell, z. B. die PowerShell-Befehlsshell für Entwickler in Visual Studio, um den folgenden Befehl auszuführen. Ändern Sie vor dem Ausführen des Befehls das Verzeichnis mit dem cd Befehl in das Verzeichnis des Serverprojekts. Der Befehl richtet einen Bezeichner für geheime Benutzerschlüssel (<UserSecretsId>) in der Projektdatei der Server-App ein, die intern von den Tools verwendet wird, um geheime Schlüssel für die App nachzuverfolgen:

dotnet user-secrets init

Führen Sie den folgenden Befehl aus, um den geheimen Clientschlüssel festzulegen. Der {SECRET} Platzhalter ist der geheime Clientschlüssel, der aus der Entra-Registrierung der App abgerufen wird:

dotnet user-secrets set "AzureAd:ClientSecret" "{SECRET}"

Wenn Sie Visual Studio verwenden, können Sie bestätigen, dass der geheime Schlüssel festgelegt ist, indem Sie in Projektmappen-Explorer mit der rechten Maustaste auf das Serverprojekt klicken und "Benutzergeheimnisse verwalten" auswählen.

Azure Key Vault

Azure Key Vault bietet einen sicheren Ansatz für die Bereitstellung des geheimen Clientschlüssels der App für die App.

Informationen zum Erstellen eines Schlüsseltresors und Festlegen eines geheimen Clientschlüssels finden Sie in der Azure Key Vault-Dokumentation, die Ressourcen für die ersten Schritte mit Azure Key Vault miteinander verknüpft. Um den Code in diesem Abschnitt zu implementieren, notieren Sie den Schlüsseltresor-URI und den geheimen Namen von Azure, wenn Sie den Schlüsseltresor und den geheimen Schlüsselschlüssel erstellen. Wenn Sie die Zugriffsrichtlinie für den geheimen Schlüssel im Zugriffsrichtlinienbereich festlegen:

  • Es ist nur die Berechtigung "Geheim abrufen" erforderlich.
  • Wählen Sie die Anwendung als Prinzipal für den geheimen Schlüssel aus.

Wichtig

Ein Schlüsseltresorschlüssel wird mit einem Ablaufdatum erstellt. Achten Sie darauf, nachzuverfolgen, wann ein Schlüsseltresorschlüssel abläuft, und erstellen Sie vor ablaufen dieses Datums einen neuen Geheimschlüssel für die App.

Die folgende GetKeyVaultSecret Methode ruft einen geheimen Schlüssel aus einem Schlüsseltresor ab. Fügen Sie diese Methode zum Serverprojekt hinzu. Passen Sie den Namespace (BlazorSample.Helpers) an ihr Projektnamespaceschema an.

Helpers/AzureHelper.cs:

using Azure;
using Azure.Identity;
using Azure.Security.KeyVault.Secrets;

namespace BlazorSample.Helpers;

public static class AzureHelper
{
    public static string GetKeyVaultSecret(string tenantId, string vaultUri, string secretName)
    {
        DefaultAzureCredentialOptions options = new()
        {
            // Specify the tenant ID to use the dev credentials when running the app locally
            // in Visual Studio.
            VisualStudioTenantId = tenantId,
            SharedTokenCacheTenantId = tenantId
        };

        var client = new SecretClient(new Uri(vaultUri), new DefaultAzureCredential(options));
        var secret = client.GetSecretAsync(secretName).Result;

        return secret.Value.Value;
    }
}

Wenn Dienste in der Datei des Serverprojekts Program registriert sind, rufen Sie den geheimen Clientschlüssel mithilfe des folgenden Codes ab, und wenden Sie es an:

var tenantId = builder.Configuration.GetValue<string>("AzureAd:TenantId")!;
var vaultUri = builder.Configuration.GetValue<string>("AzureAd:VaultUri")!;
var secretName = builder.Configuration.GetValue<string>("AzureAd:SecretName")!;

builder.Services.Configure<MicrosoftIdentityOptions>(
    OpenIdConnectDefaults.AuthenticationScheme,
    options =>
    {
        options.ClientSecret = 
            AzureHelper.GetKeyVaultSecret(tenantId, vaultUri, secretName);
    });

Wenn Sie die Umgebung steuern möchten, in der der vorangehende Code ausgeführt wird, z. B. um die lokale Ausführung des Codes zu vermeiden, da Sie sich entschieden haben, das Tool "Geheimer Manager" für die lokale Entwicklung zu verwenden, können Sie den vorherigen Code in eine bedingte Anweisung einschließen, die die Umgebung überprüft:

if (!context.HostingEnvironment.IsDevelopment())
{
    ...
}

Fügen Sie im AzureAd Abschnitt von appsettings.json" die folgenden VaultUri und SecretName Konfigurationsschlüssel und -werte hinzu:

"VaultUri": "{VAULT URI}",
"SecretName": "{SECRET NAME}"

Im vorherigen Beispiel:

  • Der {VAULT URI} Platzhalter ist der Schlüsseltresor-URI. Fügen Sie den nachgestellten Schrägstrich in den URI ein.
  • Der {SECRET NAME} Platzhalter ist der geheime Name.

Beispiel:

"VaultUri": "https://contoso.vault.azure.net/",
"SecretName": "BlazorWebAppEntra"

Die Konfiguration wird verwendet, um die Bereitstellung dedizierter Schlüsseltresor und geheimer Namen basierend auf den Umgebungskonfigurationsdateien der App zu erleichtern. Sie können z. B. unterschiedliche Konfigurationswerte für appsettings.Development.json die Entwicklung, appsettings.Staging.json beim Staging und appsettings.Production.json für die Produktionsbereitstellung bereitstellen. Weitere Informationen finden Sie unter Konfiguration von Blazor in ASP.NET Core.

Umleitung zur home Seite beim Abmelden

Wenn Benutzer durch die App navigieren, legt die LogInOrOut-Komponente (Layout/LogInOrOut.razor) ein ausgeblendetes Feld für die Rückgabe-URL (ReturnUrl) auf den Wert der aktuellen URL (currentURL) fest. Wenn sich der Nutzende von der App abmeldet, kehrt der identity-Anbieter zu der Seite zurück, von der er sich abgemeldet hat.

Wenn sich Benutzer von einer sicheren Seite abmelden, gelangen sie nach dem Abmelden zur gleichen sicheren Seite und von dort aus zurück zum Authentifizierungsprozess. Dieses Verhalten ist in Ordnung, wenn Benutzer häufig die Konten wechseln müssen. Eine alternative App-Spezifikation kann jedoch aufrufen, dass der Benutzer nach der Abmeldung zur Seite der App home oder einer anderen Seite zurückkehrt. Das folgende Beispiel zeigt, wie die Seite der App home als Rückgabe-URL für Abmeldevorgänge festgelegt wird.

Die wichtigen Änderungen an der LogInOrOut-Komponente werden im folgenden Beispiel veranschaulicht. Es ist nicht erforderlich, ein ausgeblendetes Feld für die ReturnUrl Einstellung auf die home Seite anzugeben / , da dies der Standardpfad ist. IDisposable wird nicht mehr implementiert. NavigationManager wird nicht mehr eingefügt. Der gesamte @code-Block wird entfernt.

Layout/LogInOrOut.razor:

@using Microsoft.AspNetCore.Authorization

<div class="nav-item px-3">
    <AuthorizeView>
        <Authorized>
            <form action="authentication/logout" method="post">
                <AntiforgeryToken />
                <button type="submit" class="nav-link">
                    <span class="bi bi-arrow-bar-left-nav-menu" aria-hidden="true">
                    </span> Logout @context.User.Identity?.Name
                </button>
            </form>
        </Authorized>
        <NotAuthorized>
            <a class="nav-link" href="authentication/login">
                <span class="bi bi-person-badge-nav-menu" aria-hidden="true"></span> 
                Login
            </a>
        </NotAuthorized>
    </AuthorizeView>
</div>

Problembehandlung

Logging

Die Server-App ist eine Standard-ASP.NET Core-App. Weitere Informationen finden Sie in den ASP.NET Core-Protokollierungsanleitungen zum Aktivieren einer niedrigeren Protokollierungsebene in der Server-App.

Informationen zum Aktivieren der Debug- oder Ablaufverfolgungsprotokollierung für die Blazor WebAssembly-Authentifizierung finden Sie im Abschnitt zur clientseitigen Authentifizierungsprotokollierung ASP.NET Core-Blazor-Protokollierung, wobei die Artikelversionsauswahl auf ASP.NET Core 7.0 oder höher festgelegt ist.

Häufige Fehler

  • Falsche Konfiguration der App oder des Identity-Anbieters (Identity Provider, IP)

    Die häufigsten Fehler werden durch eine falsche Konfiguration verursacht. Im Folgenden finden Sie einige Beispiele:

    • In Abhängigkeit von den Anforderungen des Szenarios verhindert eine fehlende oder falsche Autorität, Instanz, Mandanten-ID, Mandantendomäne oder Client-ID oder ein fehlender oder falscher Umleitungs-URI, dass Clients von einer App authentifiziert werden.
    • Falsche Anforderungsbereiche verhindern, dass Clients auf die Web-API-Endpunkte des Servers zugreifen können.
    • Falsche oder fehlende Server-API-Berechtigungen verhindern, dass Clients auf Server-Web-API-Endpunkte zugreifen können.
    • Das Ausführen der App an einem anderen Port als dem, der im Umleitungs-URI der App-Registrierung für die IP konfiguriert ist. Beachten Sie, dass für Microsoft Entra ID und eine App, die an einer localhost-Entwicklungstestadresse ausgeführt wird, kein Port erforderlich ist. Die Portkonfiguration der App und der Port, an dem die App ausgeführt wird, müssen jedoch für Nicht-localhost-Adressen übereinstimmen.

    Die Konfigurationsabdeckung in diesem Artikel enthält Beispiele für die richtige Konfiguration. Überprüfen Sie sorgfältig die Konfiguration, die nach App- und IP-Fehlkonfigurationen sucht.

    Wenn die Konfiguration anscheinend korrekt ist:

    • Analysieren Sie Anwendungsprotokolle.

    • Überprüfen Sie den Netzwerkdatenverkehr zwischen der Client-App und dem IP oder der Server-App mit den Entwicklertools des Browsers. Häufig wird vom IP oder von der Server-App eine präzise Fehlermeldung oder eine Meldung mit einem Hinweis auf die Ursache des Problems zurückgegeben, nachdem eine Anforderung erfolgt ist. Anleitungen zu den Entwicklertools finden Sie in den folgenden Artikeln:

    Das Dokumentationsteam berücksichtigt Feedback zur Dokumentation und zu Fehlern in Artikeln. (Legen Sie im Feedbackbereich auf dieser Seite ein Ticket an.) Es leistet jedoch keinen Produktsupport. Es gibt einige öffentliche Supportforen, die bei der Problembehandlung für eine App weiterhelfen. Es wird Folgendes empfohlen:

    Die genannten Foren werden nicht von Microsoft betrieben oder kontrolliert.

    Bei nicht sicherheitsbezogenen, nicht sensiblen und nicht vertraulichen Fehlerberichten zum Framework wird legen Sie ein Ticket für die ASP.NET Core-Produkteinheit an. Legen Sie ein Ticket für die Produkteinheit erst an, wenn Sie die Ursache eines Problems gründlich untersucht haben und es nicht selbst oder mithilfe der Community in einem öffentlichen Supportforum lösen konnten. Die Produkteinheit kann keine Problembehandlung für einzelne Apps durchführen, die aufgrund einer einfachen Fehlkonfiguration oder in Anwendungsfällen mit Drittanbieterdiensten nicht funktionieren. Wenn ein Bericht sensibler oder vertraulicher Natur ist oder eine potenzielle Sicherheitslücke im Produkt beschreibt, die von Cyberkriminellen ausgenutzt werden könnte, lesen Sie bitte Melden von Sicherheitsproblemen und Fehlern (dotnet/aspnetcore GitHub Repository).

  • Nicht autorisierter Client für ME-ID

    Info: Die Autorisierung von Microsoft.AspNetCore.Authorization.DefaultAuthorizationService[2] Authorization ist fehlgeschlagen. Diese Anforderungen wurden nicht erfüllt: DenyAnonymousAuthorizationRequirement: Erfordert einen authentifizierten Benutzer.

    Anmelderückruffehler von ME-ID:

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

    So beheben Sie den Fehler

    1. Greifen Sie im Azure-Portal auf das Manifest der App zu.
    2. Legen Sie das allowPublicClient-Attribut auf null oder true fest.

Cookies und Standortdaten

Cookies und Standortdaten können über App-Updates hinweg beibehalten werden und das Testen und die Problembehandlung beeinträchtigen. Entfernen Sie Folgendes, wenn Sie Änderungen am App-Code, Änderungen an den Benutzerkonten beim Anbieter oder Konfigurationsänderungen an Anbieter-Apps vornehmen:

  • Anmelde-Cookies von Benutzern
  • App-Cookies
  • Zwischengespeicherte und gespeicherte Standortdaten

Ein Ansatz, um zu verhindern, dass veraltete Cookies und Standortdaten das Testen und die Problembehandlung beeinträchtigen, ist folgender:

  • Browser konfigurieren
    • Verwenden Sie zum Testen einen Browser, den Sie so konfigurieren können, dass alle cookies und Standortdaten jedes Mal gelöscht werden, wenn der Browser geschlossen wird.
    • Stellen Sie sicher, dass der Browser manuell oder durch die IDE für alle Änderungen an der App, dem Testbenutzer oder der Anbieterkonfiguration geschlossen wird.
  • Verwenden Sie einen benutzerdefinierten Befehl, um in Visual Studio einen Browser im privaten oder Inkognito-Modus zu öffnen:
    • Öffnen Sie mithilfe der Schaltfläche Ausführen von Visual Studio das Dialogfeld Browserauswahl.
    • Wählen Sie die Schaltfläche Hinzufügen aus.
    • Geben Sie im Feld Programm den Pfad zu Ihrem Browser an. Die folgenden Pfade für ausführbare Dateien sind typische Installationspfade für Windows 10. Wenn Ihr Browser an einem anderen Speicherort installiert ist oder Sie nicht Windows 10 verwenden, geben Sie den Pfad zur ausführbaren Datei des Browsers an.
      • 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
    • Geben Sie im Feld Argumente die Befehlszeilenoption an, die der Browser verwendet, um im privaten oder Inkognito-Modus geöffnet zu werden. Für einige Browser ist die URL der App erforderlich.
      • Microsoft Edge: Verwenden Sie -inprivate.
      • Google Chrome: Verwenden Sie --incognito --new-window {URL}, wobei der Platzhalter {URL} die zu öffnende URL ist (z. B. https://localhost:5001).
      • Mozilla Firefox: Verwenden Sie -private -url {URL}, wobei der Platzhalter {URL} die zu öffnende URL ist (z. B. https://localhost:5001).
    • Geben Sie im Feld Anzeigename einen Namen ein. Beispielsweise Firefox Auth Testing.
    • Klicken Sie auf die Schaltfläche OK.
    • Um zu vermeiden, dass das Browserprofil für jede einzelne Testiteration einer App ausgewählt werden muss, legen Sie das Profil mithilfe der Schaltfläche Als Standard festlegen als Standard fest.
    • Stellen Sie sicher, dass der Browser von der IDE für alle Änderungen an der App, dem Testbenutzer oder der Anbieterkonfiguration geschlossen wird.

App-Upgrades

Eine funktionsfähige App kann direkt nach der Durchführung eines Upgrades für das .NET Core SDK auf dem Entwicklungscomputer oder einer Änderung der Paketversionen in der App fehlschlagen. In einigen Fällen können inkohärente Pakete eine App beschädigen, wenn größere Upgrades durchgeführt werden. Die meisten dieser Probleme können durch Befolgung der folgenden Anweisungen behoben werden:

  1. Löschen Sie die Caches für NuGet-Pakete auf dem lokalen System, indem Sie dotnet nuget locals all --clear in einer Befehlsshell ausführen.
  2. Löschen Sie die Ordner bin und obj des Projekts.
  3. Stellen Sie das Projekt wieder her und erstellen Sie es neu.
  4. Löschen Sie alle Dateien im Bereitstellungsordner auf dem Server, bevor Sie die App noch mal bereitstellen.

Hinweis

Die Verwendung von Paketversionen, die mit dem Zielframework der App nicht kompatibel sind, wird nicht unterstützt. Informationen zu einem Paket finden Sie mithilfe der NuGet Gallery oder des FuGet Package Explorer.

Ausführen der Server-App

Stellen Sie beim Testen und bei der Fehlerbehebung Blazor Web App sicher, dass Sie die Anwendung über das Serverprojekt ausführen.

Überprüfen des Benutzers

Die folgende UserClaims-Komponente kann direkt in Anwendungen verwendet werden oder als Grundlage für weitere Anpassungen dienen.

UserClaims.razor:

@page "/user-claims"
@using System.Security.Claims
@using Microsoft.AspNetCore.Authorization
@attribute [Authorize]

<PageTitle>User Claims</PageTitle>

<h1>User Claims</h1>

@if (claims.Any())
{
    <ul>
        @foreach (var claim in claims)
        {
            <li><b>@claim.Type:</b> @claim.Value</li>
        }
    </ul>
}

@code {
    private IEnumerable<Claim> claims = Enumerable.Empty<Claim>();

    [CascadingParameter]
    private Task<AuthenticationState>? AuthState { get; set; }

    protected override async Task OnInitializedAsync()
    {
        if (AuthState == null)
        {
            return;
        }

        var authState = await AuthState;
        claims = authState.User.Claims;
    }
}

Zusätzliche Ressourcen