Udostępnij za pośrednictwem

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

  • Artykuł

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 spa i Blazor aplikacji, która jest oparta na Razor stronach, wywołaj MapIdentityApi interfejs API zaplecza, aby dodać punkty końcowe interfejsu API JSON do rejestrowania i rejestrowania 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
    });

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

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

Interfejs API serwera zaplecza ustanawia cookie uwierzytelnianie za pomocą wywołania do AddIdentityCookies konstruktora 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 identity dostawcą usług lub serwerem tokenów, ale zamiast tego alternatywą dla cookie 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 Zabezpieczanie Identity zaplecza internetowego interfejsu API dla spAs.

Zamiast interfejsu API serwera zaplecza ustanawiania cookie uwierzytelniania za pomocą wywołania AddIdentityCookies w konstruktorze uwierzytelniania, interfejs API serwera konfiguruje uwierzytelnianie tokenu elementu nośnego za AddBearerToken pomocą metody rozszerzenia. 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.cspliku usuń useCookies parametr ciągu zapytania w LoginAsync metodzie metody CookieAuthenticationStateProvider:

- login?useCookies=true
+ login

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

Dodatkowe Identity scenariusze

Aby uzyskać dodatkowe Identity scenariusze udostępniane przez interfejs API, zobacz Zabezpieczanie Identity zaplecza internetowego interfejsu API dla spAs:

  • Zabezpieczanie wybranych punktów końcowych
  • Uwierzytelnianie przy użyciu tokenów
  • Uwierzytelnianie dwuskładnikowe (2FA)
  • Kody odzyskiwania
  • Zarządzanie informacjami o użytkownikach

Używanie bezpiecznych przepływów uwierzytelniania do obsługi poufnych danych i poświadczeń

Ostrzeżenie

Nie przechowuj wpisów tajnych aplikacji, parametry połączenia, poświadczeń, haseł, osobistych numerów identyfikacyjnych (PIN), prywatnego kodu C#/.NET lub kluczy prywatnych/tokenów w kodzie po stronie klienta, który jest zawsze niepewny. 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 internetowego interfejsu API zaplecza, która obsługuje magazyn użytkowników identity dla platformy ASP.NET Core Identity.
  • BlazorWasmAuth: autonomiczna Blazor WebAssembly aplikacja frontonu 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 internetowego interfejsu API zaplecza

Aplikacja internetowego interfejsu API zaplecza obsługuje sklep użytkownika identity dla platformy ASP.NET Core Identity.

Pakiety

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

Jeśli aplikacja ma używać innego EF Core dostawcy bazy danych niż dostawca w pamięci, nie twórz odwołania do pakietu w aplikacji dla programu 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 aplikacji znajduje się następująca Program konfiguracja i konfiguracja.

Użytkownik identity z uwierzytelnianiem cookie jest dodawany przez wywołanie AddAuthentication i AddIdentityCookies. Usługi sprawdzania autoryzacji są dodawane przez wywołanie metody .AddAuthorizationBuilder

Tylko zalecane w przypadku pokazów aplikacja używa EF Core dostawcy bazy danych w pamięci na potrzeby 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 testowy kod demonstracyjny rozmieszczania użytkownika, 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 EF Core wprowadzenie używa poleceń programu PowerShell do wykonywania migracji bazy danych podczas korzystania z 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 obszarze Zależności>usług SQL Server Express LocalDB wybierz wielokropek (...), a następnie pozycję Dodaj migrację, aby utworzyć migrację lub zaktualizować bazę danych w celu zaktualizowania bazy 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 zasady współużytkowania zasobów między źródłami (CORS), aby zezwolić na żądania z aplikacji frontonu i zaplecza. 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 sieciowej grupy zabezpieczeń, zobacz Rozpoczynanie pracy z siecią 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 DbContext wystąpienia, zobacz DbContext Lifetime, Configuration i Initialization (Okres istnienia, konfiguracja i inicjowanie bazy danych) w EF Core dokumentacji.

Pakiety aplikacji autonomicznych Blazor WebAssembly frontonu i kod

Autonomiczna Blazor WebAssembly aplikacja frontonu demonstruje uwierzytelnianie i autoryzację 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) obsługuje stan uwierzytelniania opartego na cookiekontach i udostępnia implementacje usług zarządzania kontami opisane przez IAccountManagement interfejs. 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 () zapewnia, że cookie poświadczenia są wysyłane z każdym żądaniem do internetowego interfejsu API zaplecza, który obsługuje Identity i obsługuje Identity magazyn danych.Identity/CookieHandler.csCookieHandler

Zapewnia wwwroot/appsettings.file punkty końcowe zaplecza i adresu URL frontonu.

Składnik App uwidacznia stan uwierzytelniania jako parametr kaskadowy. Aby uzyskać więcej informacji, zobacz ASP.NET Core authentication and authorization (Uwierzytelnianie i autoryzacja na platformie ASP.NET CoreBlazor).

Składnik MainLayout iNavMenu składnik używają AuthorizeView składnika do selektywnego wyświetlania zawartości na podstawie stanu uwierzytelniania 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 metodę, gdy zmieni się stan uwierzytelniania użytkownika. Aby zapoznać się z przykładem, zobacz LoginAsync metody CookieAuthenticationStateProvider i LogoutAsync klasy (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 umieszczonej Blazor WebAssembly w składniku AuthorizeView jest wykrywalna bez uwierzytelniania, dlatego po pomyślnym uwierzytelnieniu należy uzyskać zawartość wrażliwą z internetowego interfejsu API opartego na serwerze zaplecza. Aby uzyskać więcej informacji, zobacz następujące zasoby:

Pokaz rozmieszczania 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!wartość . Firma Leela otrzymuje Administrator Manager role autoryzacji, co umożliwia użytkownikowi dostęp do strony menedżera w /private-manager-page witrynie , ale nie na stronie edytora w witrynie /private-editor-page.

Ostrzeżenie

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

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

Role

Ze względu na problem z projektem struktury (dotnet/aspnetcore #50037) oświadczenia ról nie są wysyłane z manage/info punktu końcowego w celu utworzenia oświadczeń użytkowników dla użytkowników BlazorWasmAuth aplikacji. Oświadczenia ról są zarządzane niezależnie za pośrednictwem oddzielnego żądania w GetAuthenticationStateAsync metodzieCookieAuthenticationStateProvider klasy (Identity/CookieAuthenticationStateProvider.cs) po uwierzytelnieniu użytkownika w projekcieBackend.

W pliku CookieAuthenticationStateProviderżądanie ról jest wykonywane do /roles punktu końcowego projektu interfejsu Backend API serwera. Odpowiedź jest odczytywana w ciągu przez wywołanie metody ReadAsStringAsync(). JsonSerializer.Deserialize deserializuje ciąg do tablicy niestandardowej RoleClaim . Na koniec oświadczenia są dodawane do kolekcji oświadczeń użytkownika.

W pliku interfejsu Backend Program API serwera interfejs API minimalny zarządza /roles punktem końcowym. Oświadczenia elementu RoleClaimType są wybierane do typu anonimowego i serializowane do powrotu do projektu za BlazorWasmAuth pomocą polecenia TypedResults.Json.

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

Hosting między domenami (konfiguracja tej samej lokacji)

Przykładowe aplikacje są skonfigurowane do hostowania obu aplikacji w tej samej domenie. Jeśli hostujesz aplikację Backend w innej domenie niż BlazorWasmAuth aplikacja, usuń komentarz z kodu, który konfiguruje cookie element (ConfigureApplicationCookie) w Backend pliku 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 lokacji cookie , zobacz następujące zasoby:

Obsługa ochrony przed fałszerzami

Tylko punkt końcowy wylogowywanie (/logout) w Backend aplikacji wymaga uwagi w celu ograniczenia zagrożenia fałszerzowania żądań między witrynami (CSRF).

Punkt końcowy wylogowywał sprawdzanie pustej treści, aby zapobiec atakom CSRF. Wymagając treści, żądanie musi zostać wykonane z poziomu języka JavaScript, który jest jedynym sposobem uzyskania dostępu do uwierzytelniania cookie. Nie można uzyskać dostępu do punktu końcowego wylogowywanie za pomocą formularza POST. Zapobiega to wylogowaniu użytkownika przez złośliwą witrynę.

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

Aplikacja BlazorWasmAuth kliencka jest po prostu wymagana do przekazania pustego obiektu {} w treści żądania.

Poza punktem końcowym wylogowywaniem środki zaradcze są wymagane tylko podczas przesyłania danych formularza do serwera zakodowanego jako application/x-www-form-urlencoded, multipart/form-datalub text/plain. Blazor zarządza ograniczeniem ryzyka CSRF dla formularzy w większości przypadków. Aby uzyskać więcej informacji, zobacz omówienie uwierzytelniania i autoryzacji ASP.NET Core Blazor oraz formularzy ASP.NET CoreBlazor.

Żą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. Narzędzia programistyczne wskazówki 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 usterek struktury niezwiązanych z zabezpieczeniami, niewrażliwych i nieufnych, otwórz problem z jednostką 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

Jednym z metod zapobiegania utrzymującym się plikom cookie i danym witryny jest zakłócanie testowania i rozwiązywania problemów:

  • Konfigurowanie przeglądarki
    • Użyj przeglądarki do testowania, które można skonfigurować, aby usuwać wszystkie cookie dane witryny i za każdym razem, gdy przeglądarka jest zamknięta.
    • 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 polecenia -inprivate.
      • Google Chrome: użyj symbolu --incognito --new-window {URL}{URL} zastępczego , gdzie symbol zastępczy to adres URL do otwarcia (na przykład https://localhost:5001).
      • Mozilla Firefox: użyj symbolu -private -url {URL}zastępczego {URL} , gdzie symbol zastępczy 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, wykonując polecenie dotnet nuget locals all --clear z powłoki poleceń.
  2. Usuń foldery i obj foldery bin projektu.
  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 na temat pakietu, użyj galerii NuGet lub Eksploratora pakietów FuGet.

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