Udostępnij za pośrednictwem

Zabezpieczanie ASP.NET Core Blazor WebAssembly przy użyciu platformy ASP.NET Core Identity

  • Artykuł

Uwaga

Nie jest to najnowsza wersja tego artykułu. Aby zapoznać się z bieżącą wersją, zobacz wersję tego artykułu dla .NET 9.

Ważne

Te informacje odnoszą się do produktu w wersji wstępnej, który może zostać znacząco zmodyfikowany, zanim zostanie wydany komercyjnie. Firma Microsoft nie udziela żadnych gwarancji, jawnych lub domniemanych, w odniesieniu do informacji podanych w tym miejscu.

Aby zapoznać się z bieżącą wersją, zobacz wersję artykułu dla platformy .NET 9 .

Aplikacje autonomiczne Blazor WebAssembly można zabezpieczyć za pomocą ASP.NET Core Identity , postępując zgodnie ze wskazówkami w tym artykule.

Punkty końcowe do rejestrowania, logowania i wylogowywania

Zamiast używać domyślnego interfejsu użytkownika udostępnianego przez platformę ASP.NET Core Identity dla aplikacji SPA i Blazor, które są oparte na Razor stronach, wywołaj MapIdentityApi w API backendowym, aby dodać punkty końcowe interfejsu API JSON do rejestracji i logowania użytkowników przy użyciu platformy ASP.NET Core Identity. Identity Punkty końcowe interfejsu API obsługują również zaawansowane funkcje, takie jak uwierzytelnianie dwuskładnikowe i weryfikacja poczty e-mail.

Na kliencie wywołaj /register punkt końcowy, aby zarejestrować użytkownika przy użyciu adresu e-mail i hasła:

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

W kliencie zaloguj użytkownika za pomocą uwierzytelniania cookie przy użyciu punktu końcowego /login z ciągiem zapytania useCookies ustawionym na true:

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

API serwera zaplecza ustanawia cookie uwierzytelnianie za pomocą wywołania do AddIdentityCookies budowniczego uwierzytelniania:

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

Uwierzytelnianie przy użyciu tokenów

W przypadku scenariuszy natywnych i mobilnych, w których niektórzy klienci nie obsługują plików cookie, interfejs API logowania udostępnia parametr żądania tokenów.

Ostrzeżenie

Zalecamy używanie plików cookie dla aplikacji opartych na przeglądarce zamiast tokenów, ponieważ przeglądarka obsługuje pliki cookie bez ujawniania ich w języku JavaScript. Jeśli zdecydujesz się używać zabezpieczeń opartych na tokenach w aplikacjach internetowych, odpowiadasz za zapewnienie bezpieczeństwa tokenów.

Wystawiony jest token niestandardowy (zastrzeżony dla platformy ASP.NET Core Identity ), który może służyć do uwierzytelniania kolejnych żądań. Token powinien zostać przekazany w nagłówku Authorization jako token elementu nośnego. Dostępny jest również token odświeżania. Ten token umożliwia aplikacji żądanie nowego tokenu po wygaśnięciu starego tokenu bez wymuszania ponownego logowania użytkownika.

Tokeny nie są standardowymi tokenami sieci Web JSON (JWTs). Użycie tokenów niestandardowych jest zamierzone, ponieważ wbudowany Identity interfejs API jest przeznaczony głównie dla prostych scenariuszy. Opcja tokenu nie ma być w pełni funkcjonalnym dostawcą usług tożsamości lub serwerem tokenów, ale zamiast tego alternatywą dla cookie opcji dla klientów, którzy nie mogą używać plików cookie.

Poniższe wskazówki rozpoczynają proces implementowania uwierzytelniania opartego na tokenach przy użyciu interfejsu API logowania. Kod niestandardowy jest wymagany do ukończenia implementacji. Aby uzyskać więcej informacji, zobacz Użyj Identity do zabezpieczania zaplecza interfejsu API dla aplikacji jednostronicowych.

Zamiast tego, aby interfejs API serwera zaplecza ustanowił cookie uwierzytelnianie za pomocą wywołania AddIdentityCookies na konstruktorze uwierzytelniania, interfejs API serwera konfiguruje uwierzytelnianie tokenu typu bearer za pomocą metody rozszerzenia AddBearerToken. Określ schemat tokenów uwierzytelniania elementu nośnego za pomocą polecenia IdentityConstants.BearerScheme.

W Backend/Program.cspliku zmień usługi uwierzytelniania i konfigurację na następujące:

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

W BlazorWasmAuth/Identity/CookieAuthenticationStateProvider.cs pliku usuń useCookies parametr ciągu zapytania w LoginAsync metodzie CookieAuthenticationStateProvider:

- login?useCookies=true
+ login

Na tym etapie należy podać niestandardowy kod, aby zanalizować AccessTokenResponse na kliencie i zarządzać tokenami dostępu i odświeżania. Aby uzyskać więcej informacji, zobacz Zabezpieczanie SPA za pomocą Identity dla zaplecza interfejsu API.

Dodatkowe Identity scenariusze

Scenariusze objęte zestawem Blazor dokumentacji:

Aby uzyskać informacje na temat dodatkowych Identity scenariuszy udostępnianych przez interfejs API, zobacz Zabezpieczanie Identity zaplecza internetowego interfejsu API dla SPAs:

  • Zabezpieczanie wybranych punktów końcowych
  • Zarządzanie informacjami o użytkownikach

Stosuj bezpieczne przepływy uwierzytelniania, aby utrzymywać poufne dane i poświadczenia.

Ostrzeżenie

Nie przechowuj tajnych danych aplikacji, ciągów połączenia, poświadczeń, haseł, osobistych numerów identyfikacyjnych (PIN), prywatnego kodu C#/.NET ani kluczy prywatnych/tokenów w kodzie po stronie klienta, który jest zawsze niezabezpieczony. W środowiskach testowych/przejściowych i produkcyjnych kod po stronie Blazor serwera i internetowe interfejsy API powinny używać bezpiecznych przepływów uwierzytelniania, które unikają utrzymywania poświadczeń w kodzie projektu lub plikach konfiguracji. Poza lokalnymi testami programistycznymi zalecamy unikanie używania zmiennych środowiskowych do przechowywania poufnych danych, ponieważ zmienne środowiskowe nie są najbezpieczniejszym podejściem. W przypadku lokalnego testowania programistycznego narzędzie Secret Manager jest zalecane do zabezpieczania poufnych danych. Aby uzyskać więcej informacji, zobacz Bezpieczne utrzymywanie poufnych danych i poświadczeń.

Przykładowe aplikacje

W tym artykule przykładowe aplikacje służą jako odwołanie do Blazor WebAssembly autonomicznych aplikacji, które uzyskują dostęp do ASP.NET Core Identity za pośrednictwem internetowego interfejsu API zaplecza. Pokaz obejmuje dwie aplikacje:

  • Backend: aplikacja API zaplecza, która obsługuje magazyn tożsamości użytkownika dla ASP.NET Core Identity.
  • BlazorWasmAuth: niezależna aplikacja frontendowa Blazor WebAssembly z uwierzytelnianiem użytkownika.

Uzyskaj dostęp do przykładowych aplikacji za pośrednictwem folderu najnowszej wersji z katalogu głównego repozytorium przy użyciu następującego linku. Przykłady są udostępniane dla platformy .NET 8 lub nowszej. README Zobacz plik w folderzeBlazorWebAssemblyStandaloneWithIdentity, aby uzyskać instrukcje dotyczące uruchamiania przykładowych aplikacji.

Wyświetl lub pobierz przykładowy kod (jak pobrać)

Pakiety i kod aplikacji back-endowego interfejsu API

Aplikacja interfejsu API zaplecza obsługuje magazyn tożsamości użytkownika dla ASP.NET Core Identity.

Pakiety

Aplikacja używa następujących pakietów NuGet:

Jeśli Twoja aplikacja ma używać innego dostawcy bazy danych niż dostawca w pamięci operacyjnej, nie twórz odwołania do pakietu w aplikacji dla Microsoft.EntityFrameworkCore.InMemory.

W pliku projektu aplikacji (.csproj) skonfigurowano niezmienną globalizację .

Przykładowy kod aplikacji

Ustawienia aplikacji konfigurują adresy URL zaplecza i frontonu:

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

Plik Backend.http może służyć do testowania żądania danych pogodowych. Pamiętaj, że BlazorWasmAuth aplikacja musi być uruchomiona, aby przetestować punkt końcowy, a punkt końcowy jest zakodowany w pliku. Aby uzyskać więcej informacji, zobacz Use .http files in Visual Studio 2022 (Używanie plików HTTP w programie Visual Studio 2022).

W pliku Program znajdują się ustawienia i konfiguracja aplikacji.

Aby dodać tożsamość użytkownika z uwierzytelnianiem cookie, należy wywołać AddAuthentication i AddIdentityCookies. Usługi sprawdzania autoryzacji są dodawane przez wywołanie AddAuthorizationBuilder.

Aplikacja, zalecana tylko do pokazów, używa dostawcy bazy danych w pamięci do rejestracji kontekstu bazy danych (AddDbContext). Dostawca bazy danych w pamięci ułatwia ponowne uruchomienie aplikacji i testowanie przepływów rejestracji i logowania użytkownika. Każde uruchomienie rozpoczyna się od nowej bazy danych, ale aplikacja zawiera kod demonstracyjny do rozmieszczania użytkowników testowych, który został opisany w dalszej części tego artykułu. Jeśli baza danych zostanie zmieniona na SQLite, użytkownicy zostaną zapisani między sesjami, ale baza danych musi zostać utworzona za pośrednictwem migracji, jak pokazano w samouczku EF Corewprowadzającym†. Możesz użyć innych dostawców relacyjnych, takich jak SQL Server dla kodu produkcyjnego.

Uwaga

† Samouczek wprowadzający EF Core używa poleceń programu PowerShell do wykonywania migracji bazy danych w momencie używania programu Visual Studio. Alternatywną metodą w programie Visual Studio jest użycie interfejsu użytkownika połączonych usług:

W Eksplorator rozwiązań kliknij dwukrotnie pozycję Połączone usługi. W Service Dependencies>SQL Server Express LocalDB wybierz wielokropek (...), a następnie wybierz Dodaj migrację, aby utworzyć migrację, lub Zaktualizuj bazę danych, aby zaktualizować bazę danych.

Skonfiguruj Identity , aby używać EF Core bazy danych i uwidaczniać Identity punkty końcowe za pośrednictwem wywołań do AddIdentityCore, AddEntityFrameworkStoresi AddApiEndpoints.

Ustanowiono politykę Cross-Origin Resource Sharing (CORS), aby zezwolić na żądania z aplikacji frontendu i backendu. Rezerwowe adresy URL są konfigurowane dla zasad CORS, jeśli ustawienia aplikacji nie udostępniają tych adresów:

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

Usługi i punkty końcowe programu Swagger/OpenAPI są dołączone do dokumentacji internetowego interfejsu API i testowania programowania. Aby uzyskać więcej informacji na temat NSwag, zobacz Rozpoczynanie pracy z NSwag i ASP.NET Core.

Oświadczenia roli użytkownika są wysyłane z minimalnego interfejsu API w punkcie /roles końcowym.

Trasy są mapowane dla Identity punktów końcowych przez wywołanie metody MapIdentityApi<AppUser>().

Punkt końcowy wylogowania (/Logout) jest skonfigurowany w potoku oprogramowania pośredniczącego w celu wylogowania użytkowników.

Aby zabezpieczyć punkt końcowy, dodaj metodę RequireAuthorization rozszerzenia do definicji trasy. W przypadku kontrolera dodaj [Authorize] atrybut do kontrolera lub akcji.

Aby uzyskać więcej informacji na temat podstawowych wzorców inicjowania i konfiguracji wystąpienia DbContext, zobacz DbContext Lifetime, Configuration, and Initialization w dokumentacji EF Core.

Pakiety aplikacji niezależnych Blazor WebAssembly frontend i kod

Autonomiczna aplikacja frontendowa Blazor WebAssembly demonstruje, jak uwierzytelniać i autoryzować użytkownika w celu uzyskania dostępu do prywatnej strony internetowej.

Pakiety

Aplikacja używa następujących pakietów NuGet:

Przykładowy kod aplikacji

Folder Models zawiera modele aplikacji:

Interfejs IAccountManagement (Identity/CookieHandler.cs) zapewnia usługi zarządzania kontami.

Klasa CookieAuthenticationStateProvider (Identity/CookieAuthenticationStateProvider.cs) zarządza stanem uwierzytelniania opartym na kontach cookie i udostępnia implementacje usług zarządzania kontami określone przez interfejs IAccountManagement. Metoda LoginAsync jawnie włącza cookie uwierzytelnianie za pośrednictwem useCookies wartości trueciągu zapytania . Klasa zarządza również tworzeniem oświadczeń ról dla uwierzytelnionych użytkowników.

Klasa CookieHandler (Identity/CookieHandler.cs) zapewnia, że poświadczenia są wysyłane z każdym żądaniem do zaplecza web API, które obsługuje Identity i utrzymuje magazyn danych Identity.

wwwroot/appsettings.file zapewnia punkty końcowe URL dla części zaplecza i frontendu.

Składnik App uwidacznia stan uwierzytelniania jako parametr kaskadowy. Aby uzyskać więcej informacji, zobacz uwierzytelnianie i autoryzacja w ASP.NET Core.

Komponent MainLayout oraz komponent NavMenu korzystają z komponentu AuthorizeView do selektywnego wyświetlania zawartości na podstawie stanu uwierzytelnienia użytkownika.

Następujące składniki obsługują typowe zadania uwierzytelniania użytkowników, korzystając z IAccountManagement usług:

Składnik PrivatePage (Components/Pages/PrivatePage.razor) wymaga uwierzytelniania i pokazuje oświadczenia użytkownika.

Usługi i konfiguracja są udostępniane w Program pliku (Program.cs):

  • Procedura cookie obsługi jest zarejestrowana jako usługa o określonym zakresie.
  • Usługi autoryzacji są zarejestrowane.
  • Niestandardowy dostawca stanu uwierzytelniania jest zarejestrowany jako usługa o określonym zakresie.
  • Interfejs zarządzania kontami (IAccountManagement) jest zarejestrowany.
  • Podstawowy adres URL hosta jest skonfigurowany dla zarejestrowanego wystąpienia klienta HTTP.
  • Podstawowy adres URL zaplecza jest skonfigurowany dla zarejestrowanego wystąpienia klienta HTTP używanego do interakcji uwierzytelniania z internetowym interfejsem API zaplecza. Klient HTTP używa cookie programu obsługi, aby upewnić się, że cookie poświadczenia są wysyłane z każdym żądaniem.

Wywołaj AuthenticationStateProvider.NotifyAuthenticationStateChanged gdy zmieni się stan uwierzytelniania użytkownika. Aby zapoznać się z przykładem, zobacz metody LoginAsync i LogoutAsync klasy CookieAuthenticationStateProvider (Identity/CookieAuthenticationStateProvider.cs).

Ostrzeżenie

Składnik AuthorizeView selektywnie wyświetla zawartość interfejsu użytkownika w zależności od tego, czy użytkownik jest autoryzowany. Cała zawartość w aplikacji Blazor WebAssembly umieszczonej w składniku AuthorizeView jest wykrywalna bez uwierzytelniania, dlatego po pomyślnym uwierzytelnieniu należy uzyskać zawartość wrażliwą z serwerowego internetowego interfejsu API. Aby uzyskać więcej informacji, zobacz następujące zasoby:

Demonstracja inicjowania użytkownika testowego

Klasa SeedData (SeedData.cs) pokazuje, jak utworzyć użytkowników testowych na potrzeby programowania. Użytkownik testowy o nazwie Leela loguje się do aplikacji przy użyciu adresu leela@contoso.come-mail . Hasło użytkownika jest ustawione na Passw0rd!. Leela otrzymuje role Administrator i Manager do autoryzacji, co umożliwia jej dostęp do strony menedżera na /private-manager-page, ale nie na stronie edytora na /private-editor-page.

Ostrzeżenie

Nigdy nie zezwalaj na uruchamianie kodu użytkownika testowego w środowisku produkcyjnym. SeedData.InitializeAsync jest wywoływany tylko w środowisku Development w pliku Program:

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

Role

Żądania ról nie są zwracane z punktu końcowego manage/info, aby utworzyć żądania użytkowników dla użytkowników aplikacji BlazorWasmAuth. Oświadczenia ról są zarządzane niezależnie za pośrednictwem oddzielnego żądania w metodzie GetAuthenticationStateAsync klasy CookieAuthenticationStateProvider(Identity/CookieAuthenticationStateProvider.cs) po uwierzytelnieniu użytkownika w projekcie Backend.

W CookieAuthenticationStateProvider składane jest żądanie ról do punktu końcowego /roles projektu interfejsu API serwera Backend. Odpowiedź jest odczytywana do łańcucha przez wywołanie ReadAsStringAsync(). JsonSerializer.Deserialize deserializuje ciąg znaków na niestandardową tablicę RoleClaim. Na koniec oświadczenia są dodawane do kolekcji oświadczeń użytkownika.

W pliku API serwera BackendProgram, Minimal API zarządza końcowym punktem /roles. Oświadczenia elementu RoleClaimType są wybierane do typu anonimowego i serializowane do zwrotu do projektu z TypedResults.Json.

Punkt końcowy ról wymaga autoryzacji przez wywołanie metody RequireAuthorization. Jeśli zdecydujesz się nie używać Minimal API zamiast kontrolerów dla bezpiecznych punktów końcowych API serwera, pamiętaj, aby ustawić atrybut [Authorize] na kontrolerach lub akcjach.

Hosting między domenami (konfiguracja tego samego miejsca)

Przykładowe aplikacje są skonfigurowane do hostowania obu aplikacji w tej samej domenie. Jeśli hostujesz aplikację Backend w innej domenie niż aplikacja BlazorWasmAuth, odkomentuj kod, który konfiguruje element cookie (ConfigureApplicationCookie) w pliku Backend aplikacji Program. Wartości domyślne to:

Zmień wartości na:

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

Aby uzyskać więcej informacji na temat ustawień tej samej domeny cookie, zapoznaj się z następującymi zasobami.

Obsługa przeciwdziałania fałszerstwom

Tylko endpoint wylogowywania (/logout) w aplikacji Backend wymaga uwagi w celu ograniczenia zagrożenia ataku CSRF.

Punkt końcowy wylogowywał sprawdzanie pustej treści, aby zapobiec atakom CSRF. Ponieważ wymagane jest ciało, żądanie musi zostać wykonane przy użyciu języka JavaScript, ponieważ jest to jedyny sposób uzyskania dostępu do uwierzytelniania cookie. Nie można uzyskać dostępu do punktu końcowego wylogowania za pomocą formularzowego żądania POST. To zapobiega wylogowaniu użytkownika przez złośliwą stronę internetową.

Ponadto punkt końcowy jest chroniony przez autoryzację (RequireAuthorization), aby uniemożliwić dostęp anonimowy.

Wystarczy, aby aplikacja kliencka przekazała pusty obiekt {} w treści żądania.

Poza punktem końcowym ścieżką wylogowania, środki zaradcze przeciwko fałszerstwom są wymagane tylko podczas przesyłania danych formularza do serwera zakodowanego jako application/x-www-form-urlencoded, multipart/form-data lub text/plain. Blazor zarządza ograniczeniem ryzyka CSRF dla formularzy w większości przypadków. Aby uzyskać więcej informacji, zobacz ASP.NET Core Blazor uwierzytelnianie i autoryzację oraz przegląd formularzy Blazor ASP.NET Core.

Żądania do innych punktów końcowych interfejsu API serwera (internetowy interfejs API) z zakodowaną zawartością application/jsoni włączonym mechanizmem CORS nie wymagają ochrony CSRF. Dlatego dla punktu końcowego Backend przetwarzania danych () aplikacji (/data-processing) nie jest wymagana ochrona CSRF. Punkt końcowy ról (/roles) nie wymaga ochrony CSRF, ponieważ jest to punkt końcowy GET, który nie modyfikuje żadnego stanu.

Rozwiązywanie problemów

Rejestrowanie

Aby włączyć rejestrowanie debugowania lub śledzenia na potrzeby Blazor WebAssembly uwierzytelniania, zobacz rejestrowanie ASP.NET CoreBlazor.

Typowe błędy

Sprawdź konfigurację każdego projektu. Upewnij się, że adresy URL są poprawne:

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

Jeśli konfiguracja jest poprawna:

  • Analizowanie dzienników aplikacji.

  • Sprawdź ruch sieciowy między aplikacją BlazorWasmAuth i Backend aplikacją przy użyciu narzędzi deweloperskich przeglądarki. Często dokładny komunikat o błędzie lub komunikat zawierający wskazówki dotyczące przyczyn problemu jest zwracany do klienta przez aplikację zaplecza po wykonaniu żądania. Wskazówki dotyczące narzędzi programistycznych można znaleźć w następujących artykułach:

  • Google Chrome (dokumentacja Google)

  • Microsoft Edge

  • Mozilla Firefox (dokumentacja Mozilla)

Zespół dokumentacji odpowiada na informacje zwrotne i błędy w artykułach. Otwórz problem, korzystając z linku Otwórz problem z dokumentacją w dolnej części artykułu. Zespół nie może zapewnić pomocy technicznej dla produktów. Dostępnych jest kilka publicznych forów pomocy technicznej, które ułatwiają rozwiązywanie problemów z aplikacją. Zalecamy:

Poprzednie fora nie należą do firmy Microsoft ani nie są kontrolowane przez firmę Microsoft.

W przypadku raportów o błędach w strukturze, które nie są związane z bezpieczeństwem, nie są wrażliwe ani poufne, zgłoś problem do zespołu produktu ASP.NET Core. Nie otwieraj problemu z jednostką produktu, dopóki nie zbadasz dokładnie przyczyny problemu i nie możesz go rozwiązać samodzielnie i z pomocą społeczności na publicznym forum pomocy technicznej. Jednostka produktu nie może rozwiązywać problemów z poszczególnymi aplikacjami, które są uszkodzone z powodu prostej błędnej konfiguracji lub przypadków użycia obejmujących usługi innych firm. Jeśli raport jest poufny lub poufny lub opisuje potencjalną lukę w zabezpieczeniach produktu, którą mogą wykorzystać cyberataki, zobacz Raportowanie problemów z zabezpieczeniami i usterek (dotnet/aspnetcorerepozytorium GitHub).

Pliki cookie i dane witryn

Pliki cookie i dane witryn mogą być utrwalane w aktualizacjach aplikacji i zakłócać testowanie i rozwiązywanie problemów. Wyczyść następujące informacje podczas wprowadzania zmian w kodzie aplikacji, zmian konta użytkownika lub zmian konfiguracji aplikacji:

  • Pliki cookie logowania użytkownika
  • Pliki cookie aplikacji
  • Buforowane i przechowywane dane lokacji

Jedną z metod zapobiegania wpływowi utrzymujących się plików cookie i danych witryny na testowanie i rozwiązywanie problemów jest:

  • Konfigurowanie przeglądarki
    • Użyj przeglądarki do testowania, którą można skonfigurować, aby za każdym razem, gdy jest zamykana, usuwać wszystkie dane witryny i cookie.
    • Upewnij się, że przeglądarka jest zamknięta ręcznie lub przez środowisko IDE w celu zmiany konfiguracji aplikacji, użytkownika testowego lub dostawcy.
  • Użyj polecenia niestandardowego, aby otworzyć przeglądarkę w trybie InPrivate lub Incognito w programie Visual Studio:
    • Otwórz okno dialogowe Przeglądaj za pomocą z przycisku Uruchom programu Visual Studio.
    • Kliknij przycisk Dodaj.
    • Podaj ścieżkę do przeglądarki w polu Program . Następujące ścieżki wykonywalne to typowe lokalizacje instalacji systemu Windows 10. Jeśli przeglądarka jest zainstalowana w innej lokalizacji lub nie używasz systemu Windows 10, podaj ścieżkę do pliku wykonywalnego przeglądarki.
      • 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
    • W polu Argumenty podaj opcję wiersza polecenia używaną przez przeglądarkę do otwierania w trybie InPrivate lub Incognito. Niektóre przeglądarki wymagają adresu URL aplikacji.
      • Microsoft Edge: użyj -inprivate.
      • Google Chrome: użyj --incognito --new-window {URL}, gdzie symbol {URL} to adres URL do otwarcia (na przykład https://localhost:5001).
      • Mozilla Firefox: użyj -private -url {URL}, gdzie {URL} jest adresem URL do otwarcia (na przykład https://localhost:5001).
    • Podaj nazwę w polu Przyjazna nazwa . Na przykład Firefox Auth Testing.
    • Wybierz przycisk OK.
    • Aby uniknąć konieczności wybierania profilu przeglądarki dla każdej iteracji testowania za pomocą aplikacji, ustaw profil jako domyślny przy użyciu przycisku Ustaw jako domyślny .
    • Upewnij się, że przeglądarka jest zamknięta przez środowisko IDE w celu zmiany konfiguracji aplikacji, użytkownika testowego lub dostawcy.

Uaktualnienia aplikacji

Działająca aplikacja może zakończyć się niepowodzeniem natychmiast po uaktualnieniu zestawu .NET Core SDK na komputerze deweloperskim lub zmianie wersji pakietów w aplikacji. W niektórych przypadkach niespójne pakiety mogą spowodować przerwanie aplikacji podczas przeprowadzania głównych uaktualnień. Większość z tych problemów można rozwiązać, wykonując następujące instrukcje:

  1. Wyczyść pamięć podręczną pakietów NuGet systemu lokalnego, uruchamiając polecenie dotnet nuget locals all --clear z powłoki poleceń.
  2. Usuń foldery projektu bin i obj.
  3. Przywracanie i ponowne kompilowanie projektu.
  4. Usuń wszystkie pliki w folderze wdrażania na serwerze przed ponownym wdrożeniem aplikacji.

Uwaga

Korzystanie z wersji pakietów niezgodnych z platformą docelową aplikacji nie jest obsługiwane. Aby uzyskać informacje o pakiecie, skorzystaj z Galerii NuGet.

Sprawdzanie oświadczeń użytkownika

Aby rozwiązać problemy z oświadczeniami użytkowników, następujący UserClaims składnik może być używany bezpośrednio w aplikacjach lub służyć jako podstawa dalszego dostosowywania.

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;
        }
    }
}

Dodatkowe zasoby