Freigeben über

Sichern von ASP.NET Core Blazor WebAssembly mit ASP.NET Core Identity

  • Artikel

Hinweis

Dies ist nicht die neueste Version dieses Artikels. Die aktuelle Version finden Sie in der .NET 9-Version dieses Artikels.

Wichtig

Diese Informationen beziehen sich auf ein Vorabversionsprodukt, das vor der kommerziellen Freigabe möglicherweise noch wesentlichen Änderungen unterliegt. Microsoft gibt keine Garantie, weder ausdrücklich noch impliziert, hinsichtlich der hier bereitgestellten Informationen.

Die aktuelle Version finden Sie in der .NET 9-Version dieses Artikels.

Sie können eigenständige Blazor WebAssembly-Apps können mit ASP.NET Core Identity sichern, indem Sie den Anweisungen in diesem Artikel folgen.

Endpunkte zum Registrieren, Anmelden und Abmelden

Anstatt die von ASP.NET Core Identity bereitgestellte Standard-UI für SPA- und Blazor-Apps zu verwenden, die auf Razor-Seiten basiert, rufen Sie MapIdentityApi in einer Backend-API auf, um JSON-API-Endpunkte für die Registrierung und Anmeldung von Benutzenden mit ASP.NET Core Identity hinzuzufügen. Identity-API-Endpunkte unterstützen auch erweiterte Features, z. B. Zwei-Faktor-Authentifizierung und E-Mail-Überprüfung.

Rufen Sie auf dem Client den /register-Endpunkt auf, um Benutzer*innen mit ihren E-Mail-Adressen und dem Kennwörtern zu registrieren:

var result = await _httpClient.PostAsJsonAsync(
    "register", new
    {
        email,
        password
    });

Melden Sie auf dem Client Benutzer*innen mit cookie-Authentifizierung über den /login-Endpunkt mit der auf true festgelegten useCookies-Abfragezeichenfolge an:

var result = await _httpClient.PostAsJsonAsync(
    "login?useCookies=true", new
    {
        email,
        password
    });

Die Back-End-Server-API richtet die cookie-Authentifizierung mit einem Aufruf von AddIdentityCookies im Authentifizierungs-Generator ein:

builder.Services
    .AddAuthentication(IdentityConstants.ApplicationScheme)
    .AddIdentityCookies();

Tokenauthentifizierung

Für native und mobile Szenarien, in denen einige Clients keine Cookies unterstützen, bietet die Login-API einen Parameter zur Anforderung von Token.

Warnung

Wir empfehlen die Verwendung von Cookies für browserbasierte Anwendungen anstelle von Token, da der Browser Cookies verarbeitet, ohne sie für JavaScript freizugeben. Wenn Sie sich dafür entscheiden, tokenbasierte Sicherheit in Web-Apps zu verwenden, müssen Sie sicherstellen, dass die Token sicher bleiben.

Ein benutzerdefiniertes Token (also ein proprietäres Token der ASP.NET Core-Identity-Plattform) wird ausgegeben und kann zum Authentifizieren nachfolgender Anforderungen verwendet werden. Das Token sollte im Authorization-Header als Bearertoken übergeben werden. Außerdem wird ein Aktualisierungstoken bereitgestellt. Mit diesem Token kann die App ein neues Token anfordern, wenn das alte abläuft, ohne dass sich die Benutzer*innen erneut anmelden müssen.

Bei den Token handelt es sich nicht um standardmäßige JSON-Web-Tokens (JWTs). Die Verwendung benutzerdefinierter Token ist beabsichtigt, da die integrierte Identity-API in erster Linie für einfache Szenarien vorgesehen ist. Die Token-Option ist nicht als voll funktionsfähiger identity-Dienstanbieter oder Token-Server gedacht, sondern als Alternative zur cookie-Option für Clients, die keine Cookies verwenden können.

Der folgende Leitfaden beginnt mit der Implementierung der tokenbasierten Authentifizierung mit der Anmelde-API. Benutzerdefinierter Code ist erforderlich, um die Implementierung abzuschließen. Weitere Informationen finden Sie unter Verwenden von Identity zum Sichern eines Web-API-Back-Ends für SPAs.

Anstatt dass die Back-End-Server-API die cookie-Authentifizierung mit einem Aufruf von AddIdentityCookies auf dem Authentifizierungs-Generator herstellt, richtet die Server-API die Bearertokenauthentifizierung mit der AddBearerToken-Erweiterungsmethode ein. Legen Sie das Schema für Bearerauthentifizierungstoken mit IdentityConstants.BearerScheme fest.

Ändern Sie in Backend/Program.cs die Authentifizierungsdienste und die Konfiguration wie folgt:

builder.Services
    .AddAuthentication()
    .AddBearerToken(IdentityConstants.BearerScheme);

Entfernen Sie in BlazorWasmAuth/Identity/CookieAuthenticationStateProvider.cs den useCookies-Abfragezeichenfolgenparameter in der LoginAsync-Methode der CookieAuthenticationStateProvider:

- login?useCookies=true
+ login

An diesem Punkt müssen Sie benutzerdefinierten Code bereitstellen, um AccessTokenResponse auf dem Client zu analysieren und die Zugriffs- und Aktualisierungstoken zu verwalten. Weitere Informationen finden Sie unter Verwenden von Identity zum Sichern eines Web-API-Back-Ends für SPAs.

Zusätzliche Identity-Szenarien

Vom Dokumentationssatz abgedeckte Blazor Szenarien:

Informationen zu zusätzlichen Identity Szenarien, die von der API bereitgestellt werden, finden Sie unter Verwendung Identity eines Web-API-Back-Ends für SPAs:

  • Sichere ausgewählte Endpunkte
  • Zweistufige Authentifizierung (2FA) und Wiederherstellungscode
  • Verwaltung von Benutzerinformationen

Verwenden von sicheren Authentifizierungsflüssen zum Verwalten vertraulicher Daten und Anmeldeinformationen

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".

Beispiel-Apps

In diesem Artikel dienen Beispiel-Apps als Referenz für eigenständige Blazor WebAssembly-Apps, die über eine Back-End-Web-API auf ASP.NET Core Identity zugreifen. Die Demonstration umfasst zwei Apps:

  • Backend: Eine Backend-Web-API-App, die Benutzer-identity-Speicher für ASP.NET Core-Identity verwaltet.
  • BlazorWasmAuth: Eine eigenständige Blazor WebAssembly-Front-End-App mit Benutzerauthentifizierung.

Sie können über den Repositorystamm über folgenden Link auf die Beispiel-Apps im neuesten Versionsordner zugreifen. Die Beispiele werden für .NET 8 oder höher bereitgestellt. In der README-Datei im Ordner BlazorWebAssemblyStandaloneWithIdentity finden Sie Schritte zum Ausführen der Beispiel-Apps.

Anzeigen oder Herunterladen von Beispielcode (Vorgehensweise zum Herunterladen)

App-Pakete und -Code für die Back-End-Web-API

Die Back-End-Web-API-App verwaltet einen Benutzer-identity-Speicher für ASP.NET Core-Identity.

Packages

Die App verwendet die folgenden NuGet-Pakete:

Wenn Ihre App einen anderen EF Core-Datenbankanbieter als den In-Memory-Anbieter verwenden soll, dürfen Sie keinen Paketverweis in Ihrer App auf Microsoft.EntityFrameworkCore.InMemory erstellen.

In der Projektdatei der App (.csproj) wird die invariante Globalisierung konfiguriert.

Code der Beispiel-App

App-Einstellungen konfigurieren Back-End- und Frontend-URLs:

  • Backend-App (BackendUrl): https://localhost:7211
  • BlazorWasmAuth-App (FrontendUrl): https://localhost:7171

Die Backend.http-Datei kann zum Testen der Wetterdatenanforderung verwendet werden. Beachten Sie, dass die BlazorWasmAuth-App 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.

Das folgende Setup und die folgende Konfiguration finden Sie in der Program-Datei der App.

Benutzende identity mit cookie-Authentifizierung werden durch Aufruf von AddAuthentication und AddIdentityCookies hinzugefügt. Dienste für Autorisierungsprüfungen durch einen Aufruf von AddAuthorizationBuilder hinzugefügt.

Die App verwendet den EF Core-In-Memory-Datenbankanbieter für die Datenbankkontextregistrierung (AddDbContext). Dies wird nur für Demonstrationen empfohlen. Der In-Memory-Datenbankanbieter erleichtert den Neustart der App sowie das Testen der Registrierungs- und Benutzeranmeldungsflüsse. Jede Ausführung beginnt mit einer neuen Datenbank, aber die App enthält Testbenutzer-Seeding-Democode, der weiter unten in diesem Artikel beschrieben wird. Wenn die Datenbank in SQLite geändert wird, werden Benutzer zwischen Sitzungen gespeichert, die Datenbank muss jedoch durch Migrationen erstellt werden, wie im Tutorial EF Core „Erste Schritte“† erläutert. Sie können andere relationale Anbieter wie SQL Server für Ihren Produktionscode verwenden.

Hinweis

†Das EF Core-Tutorial mit ersten Schritten verwendet PowerShell-Befehle zum Ausführen von Datenbankmigrationen bei Verwendung von Visual Studio. Eine alternative Methode in Visual Studio besteht darin, die Benutzeroberfläche für verbundene Dienste zu verwenden:

Doppelklicken Sie im Projektmappen-Explorer auf Verbundene Dienste. Wählen Sie unter Dienstabhängigkeiten>SQL Server Express LocalDB die Auslassungspunkte (...), gefolgt von entweder Migration hinzufügen, um eine Migration zu erstellen oder Datenbank aktualisieren, um die Datenbank zu aktualisieren.

Konfigurieren Sie Identity für die Verwendung der EF Core -Datenbank und machen Sie die Identity-Endpunkte über die Aufrufe von AddIdentityCore, AddEntityFrameworkStores und AddApiEndpoints verfügbar.

Es wird eine CORS-Richtlinie (Cross-Origin Resource Sharing) eingerichtet, um Anforderungen der Front-End- und Back-End-Apps zuzulassen. Fallback-URLs werden für die CORS-Richtlinie konfiguriert, wenn die App-Einstellungen diese nicht bereitstellen:

  • Backend-App (BackendUrl): https://localhost:5001
  • BlazorWasmAuth-App (FrontendUrl): https://localhost:5002

Dienste und Endpunkte für Swagger/OpenAPI sind für die Web-API-Dokumentation und für Entwicklungstests enthalten. Weitere Informationen zu NSwag finden Sie unter Erste Schritte mit NSwag und ASP.NET Core.

Benutzerrollenansprüche werden von einer Minimalen API am /roles-Endpunkt gesendet.

Routen für Identity-Endpunkte werden durch Aufrufen von MapIdentityApi<AppUser>() zugeordnet.

Ein Abmeldeendpunkt (/Logout) wird in der Middlewarepipeline konfiguriert, um Benutzer abzumelden.

Um einen Endpunkt zu sichern, fügen Sie der Routendefinition die Erweiterungsmethode RequireAuthorization hinzu. Fügen Sie Controllern oder Aktionen das [Authorize]-Attribut hinzu.

Weitere Informationen zu grundlegenden Mustern für die Initialisierung und Konfiguration einer DbContext-Instanz finden Sie in der EF Core-Dokumentation unter DbContext-Lebensdauer, -Konfiguration und -Initialisierung.

Eigenständige Blazor WebAssembly-App-Pakete und -Code für das Front-End

Eine eigenständige Blazor WebAssembly-Frontend-App veranschaulicht die Benutzerauthentifizierung und -autorisierung für den Zugriff auf eine private Webseite.

Packages

Die App verwendet die folgenden NuGet-Pakete:

Code der Beispiel-App

Der Ordner Models enthält die folgenden App-Modelle:

Die IAccountManagement-Schnittstelle (Identity/CookieHandler.cs) stellt Kontoverwaltungsdienste bereit.

Die CookieAuthenticationStateProvider-Klasse (Identity/CookieAuthenticationStateProvider.cs) behandelt den Zustand für die cookie-basierte Authentifizierung und stellt Implementierungen für den Kontoverwaltungsdienst bereit, die von der IAccountManagement-Schnittstelle beschrieben werden. Die LoginAsync-Methode aktiviert die cookie-Authentifizierung explizit über den useCookies-Abfragezeichenfolgenwert von true. Die Klasse verwaltet auch das Erstellen von Rollenansprüchen für authentifizierte Benutzer.

Die CookieHandler-Klasse (Identity/CookieHandler.cs) stellt sicher, dass mit jeder Anforderung cookie-Anmeldeinformationen an die Back-End-Web-API gesendet werden, die die Identity und den Identity-Datenspeicher verwaltet.

wwwroot/appsettings.file stellt Back-End- und Front-End-URL-Endpunkte bereit.

Die App-Komponente machet den Authentifizierungsstatus als kaskadierender Parameter verfügbar. Weitere Informationen hierzu finden Sie unter Authentifizierung und Autorisierung in ASP.NET Core Blazor.

Die MainLayout- und die NavMenu-Komponente verwenden die AuthorizeView-Komponente, um Inhalte basierend auf dem Authentifizierungsstatus des Benutzers selektiv anzuzeigen.

Die folgenden Komponenten behandeln allgemeine Benutzerauthentifizierungsaufgaben und verwenden IAccountManagement-Dienste:

Die PrivatePage-Komponente (Components/Pages/PrivatePage.razor) erfordert eine Authentifizierung und zeigt die Ansprüche des Benutzers an.

Dienste und die Konfigurationen werden in der Program-Datei (Program.cs) bereitgestellt:

  • Der cookie-Handler wird als bereichsbezogener Dienst registriert.
  • Autorisierungsdienste werden registriert.
  • Der Anbieter für den benutzerdefinierten Authentifizierungsstatus wird als bereichsbezogener Dienst registriert.
  • Die Kontoverwaltungsschnittstelle (IAccountManagement) wird registriert.
  • Die Basishost-URL wird für eine registrierte HTTP-Clientinstanz konfiguriert.
  • Die Basis-Back-End-URL wird für eine registrierte HTTP-Clientinstanz konfiguriert, die für Authentifizierungsinteraktionen mit der Back-End-Web-API verwendet wird. Der HTTP-Client verwendet den cookie-Handler, um sicherzustellen, dass mit jeder Anforderung cookie-Anmeldeinformationen gesendet werden.

Rufen Sie AuthenticationStateProvider.NotifyAuthenticationStateChanged auf, wenn sich der Authentifizierungsstatus des Benutzers ändert. Ein Beispiel dafür finden Sie in den LoginAsync- und LogoutAsync-Methoden der CookieAuthenticationStateProvider-Klasse (Identity/CookieAuthenticationStateProvider.cs).

Warnung

Die AuthorizeView-Komponente zeigt selektiv den Inhalt der Benutzeroberfläche an, abhängig davon, ob der Benutzer dazu berechtigt ist. Alle Inhalte in einer Blazor WebAssembly-App, die in einer AuthorizeView-Komponente platziert werden, können ohne Authentifizierung erkannt werden, sodass vertrauliche Inhalte aus einer serverbasierten Back-End-Web-API abgerufen werden sollten, nachdem die Authentifizierung erfolgreich war. Weitere Informationen finden Sie in den folgenden Ressourcen:

Demonstration des Testbenutzer-Seedings

Die SeedData-Klasse (SeedData.cs) veranschaulicht, wie Testbenutzer für die Entwicklung erstellt werden. Der Testbenutzer namens Leela meldet sich mit der E-Mail-Adresse leela@contoso.com bei der App an. Das Kennwort des Benutzers ist auf Passw0rd! festgelegt. Leela werden Administrator- und Manager-Rollen für die Autorisierung erteilt, die es dem Benutzer ermöglichen, auf die Manager-Seite unter /private-manager-page, aber nicht auf die Editorseite unter /private-editor-pagezuzugreifen.

Warnung

Testbenutzercode kann niemals in einer Produktionsumgebung ausgeführt werden. SeedData.InitializeAsync wird nur in der Development-Umgebung in der Program-Datei aufgerufen:

if (builder.Environment.IsDevelopment())
{
    await using var scope = app.Services.CreateAsyncScope();
    await SeedData.InitializeAsync(scope.ServiceProvider);
}

Rollen

Rollenansprüche werden nicht vom manage/info Endpunkt zurückgesendet, um Benutzeransprüche für Benutzer der BlazorWasmAuth App zu erstellen. Rollenansprüche werden unabhängig von einer separaten Anforderung in der GetAuthenticationStateAsync-Methode der CookieAuthenticationStateProvider-Klasse (Identity/CookieAuthenticationStateProvider.cs) verwaltet, nachdem der Benutzer im Backend-Projekt authentifiziert wurde.

In der CookieAuthenticationStateProvider wird eine Rollenanforderung an den /roles-Endpunkt des Backend-Server-API-Projekts gesendet. Die Antwort wird durch Aufrufen von ReadAsStringAsync() in eine Zeichenfolge gelesen. JsonSerializer.Deserialize deserialisiert die Zeichenfolge in ein benutzerdefiniertes RoleClaim-Array. Schließlich werden die Ansprüche der Anspruchssammlung des Benutzers hinzugefügt.

In der Program-Datei der Backend-Server-API verwaltet eine Minimale API den /roles-Endpunkt. Ansprüche von RoleClaimType werden in einem anonymen Typ ausgewählt und serialisiert, um zum BlazorWasmAuth-Projekt mit TypedResults.Json zurückzukehren.

Der Rollenendpunkt erfordert eine Autorisierung durch Aufruf von RequireAuthorization. Wenn Sie sich entscheiden, keine minimalen APIs zugunsten von Controllern für sichere Server-API-Endpunkte zu verwenden, müssen Sie das [Authorize]-Attribut auf Controllern oder Aktionen festlegen.

Domänenübergreifendes Hosting (Konfiguration desselben Standorts)

Die Beispiel-Apps sind für das Hosten beider Apps auf derselben Weise konfiguriert Standard. Wenn Sie die Backend App an einer anderen Stelle hosten Standard als die BlazorWasmAuth App, heben Sie die Kommentare des Codes auf, der die cookie (ConfigureApplicationCookie) In der Backend App-Datei Program konfiguriert. Die Standardwerte lauten wie folgt:

Ändern Sie die Werte in:

- options.Cookie.SameSite = SameSiteMode.Lax;
- options.Cookie.SecurePolicy = CookieSecurePolicy.SameAsRequest;
+ options.Cookie.SameSite = SameSiteMode.None;
+ options.Cookie.SecurePolicy = CookieSecurePolicy.Always;

Weitere Informationen zu Einstellungen für die gleiche Website cookie finden Sie in den folgenden Ressourcen:

Unterstützung des Schutzes vor Fälschung

Nur der Abmeldungsendpunkt (/logout) in der Backend App erfordert Aufmerksamkeit, um die Bedrohung von der websiteübergreifenden Anforderungsfälschung (CSRF)zu verringern.

Der Abmeldeendpunkt sucht nach einem leeren Textkörper, um CSRF-Angriffe zu verhindern. Durch die Anforderung eines Textkörpers muss die Anforderung von JavaScript erfolgen, was die einzige Möglichkeit für den Zugriff auf die Authentifizierung cookie ist. Auf den Abmeldeendpunkt kann von einem formularbasierten POST nicht zugegriffen werden. Dadurch wird verhindert, dass eine böswillige Website den Benutzer abmeldet.

Darüber hinaus ist der Endpunkt durch Autorisierung (RequireAuthorization) geschützt, um anonymen Zugriff zu verhindern.

Die BlazorWasmAuth Client-App ist einfach erforderlich, um ein leeres Objekt {} im Textkörper der Anforderung zu übergeben.

Außerhalb des Abmeldungsendpunkts ist eine Antiforgery-Entschärfung nur erforderlich, wenn Formulardaten an den Server gesendet werden, der als application/x-www-form-urlencoded, multipart/form-data oder text/plain codiert ist. Blazor verwaltet CSRF-Entschärfung für Formulare in den meisten Fällen. Weitere Informationen finden Sie unter ASP.NET Core Blazor-Authentifizierung und -Autorisierung und ASP.NET Core Blazor-Formularübersicht.

Anforderungen an andere Server-API-Endpunkte (Web-API) mit application/json-codierten Inhalten und CORS-aktiviert erfordern keinen CSRF-Schutz. Aus diesem Grund ist kein CSRF-Schutz für den Datenverarbeitungsendpunkt (/data-processing) der Backend App erforderlich. Der Rollenendpunkt (/roles) benötigt keinen CSRF-Schutz, da es sich um einen GET-Endpunkt handelt, der keinen Zustand ändert.

Problembehandlung

Protokollierung

Informationen zum Aktivieren der Debugging- oder Ablaufverfolgungsprotokollierung für die Blazor WebAssembly-Authentifizierung finden Sie unter ASP.NET Core Blazor-Protokollierung.

Häufige Fehler

Überprüfen Sie die Konfiguration der einzelnen Projekte. Vergewissern Sie sich, dass die URLs korrekt sind:

  • Backend-Projekt
    • appsettings.json
      • BackendUrl
      • FrontendUrl
    • Backend.http: Backend_HostAddress
  • BlazorWasmAuth Projekt: wwwroot/appsettings.json
    • BackendUrl
    • FrontendUrl

Wenn die Konfiguration anscheinend korrekt ist:

  • Analysieren Sie Anwendungsprotokolle.

  • Untersuchen Sie den Netzwerkdatenverkehr zwischen der BlazorWasmAuth-Anwendung und der Backend-Anwendung mit den Entwicklertools des Browsers. Oft wird eine genaue Fehlermeldung oder eine Meldung mit einem Hinweis auf die Ursache des Problems von der Backend-Anwendung an den Client zurückgegeben, nachdem eine Anforderung gestellt wurde. Anleitungen zu den Entwicklertools finden Sie in den folgenden Artikeln:

  • Google Chrome (Google-Dokumentation)

  • Microsoft Edge

  • Mozilla Firefox (Mozilla-Dokumentation)

Das Dokumentationsteam reagiert auf Feedback zu Dokumenten und Fehlern in Artikeln. Öffnen Sie ein Problem mit dem Link Dokumentationsproblem öffnen am Ende des Artikels. Das Team kann keinen Produktsupport bereitstellen. 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).

Cookies und Standortdaten

Cookies und Standortdaten können über App-Updates hinweg beibehalten werden und das Testen und die Problembehandlung beeinträchtigen. Löschen Sie die folgenden Punkte, wenn Sie Änderungen am Anwendungscode, am Benutzerkonto oder an der Anwendungskonfiguration 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.

Überprüfen der Ansprüche des Benutzers

Um Probleme mit Benutzeransprüchen zu beheben, kann die folgende UserClaims-Komponente direkt in Anwendungen verwendet oder als Grundlage für weitere Anpassungen dienen.

UserClaims.razor:

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

<PageTitle>User Claims</PageTitle>

<h1>User Claims</h1>

**Name**: @AuthenticatedUser?.Identity?.Name

<h2>Claims</h2>

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

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

    public ClaimsPrincipal? AuthenticatedUser { get; set; }

    protected override async Task OnInitializedAsync()
    {
        if (AuthenticationState is not null)
        {
            var state = await AuthenticationState;
            AuthenticatedUser = state.User;
        }
    }
}

Zusätzliche Ressourcen