Sdílet prostřednictvím

Zabezpečení ASP.NET Core Blazor WebAssembly s využitím ASP.NET Core Identity

Note

Toto není nejnovější verze tohoto článku. Aktuální verzi najdete ve verzi .NET 10 tohoto článku.

Blazor WebAssembly Samostatné aplikace je možné zabezpečit pomocí ASP.NET Core Identity podle pokynů v tomto článku.

Koncové body pro registraci, přihlášení a odhlášení

Místo použití výchozího uživatelského rozhraní poskytovaného ASP.NET Core Identity pro SPA a Blazor aplikace založené na Razor Pages volejte MapIdentityApi z back-endového rozhraní API, abyste přidali koncové body JSON API pro registraci a přihlašování uživatelů pomocí ASP.NET Core Identity. Identity Koncové body rozhraní API také podporují pokročilé funkce, jako je dvojúrovňové ověřování a ověřování e-mailů.

V klientovi zavolejte /register koncový bod a zaregistrujte uživatele s jeho e-mailovou adresou a heslem:

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

Na klientovi přihlaste uživatele s ověřením cookie pomocí koncového bodu /login s dotazovým řetězcem nastaveným na useCookies:

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

Rozhraní API back-endového serveru vytváří cookie ověřování pomocí volání AddIdentityCookies tvůrce ověřování:

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

Ověřování tokenů

Pro nativní a mobilní scénáře, kdy někteří klienti nepodporují soubory cookie, poskytuje rozhraní API pro přihlášení parametr pro vyžádání tokenů.

Warning

Místo tokenů doporučujeme používat soubory cookie pro aplikace založené na prohlížeči, protože prohlížeč zpracovává soubory cookie bez jejich zveřejnění v JavaScriptu. Pokud se rozhodnete používat zabezpečení založené na tokenech ve webových aplikacích, zodpovídáte za zabezpečení tokenů.

Vystavil se vlastní token (který je proprietární pro platformu ASP.NET Core Identity ), který se dá použít k ověřování následných požadavků. Token by měl být předán v hlavičce Authorization jako nosný token. Je poskytován také obnovovací token. Tento token umožňuje aplikaci požádat o nový token, když vyprší platnost starého tokenu, aniž by uživatel museli znovu přihlásit.

Tokeny nejsou standardní webové tokeny JSON (JWT). Použití vlastních tokenů je záměrné, protože integrované Identity rozhraní API je určené především pro jednoduché scénáře. Možnost tokenu není určená jako plně funkční zprostředkovatel služby identit nebo server tokenů, ale alternativou k možnosti cookie pro klienty, kteří nemůžou používat soubory cookie.

Následující doprovodné materiály začínají procesem implementace ověřování založeného na tokenech s přihlašovacím rozhraním API. K dokončení implementace se vyžaduje vlastní kód. Další informace najdete v tématu Použití Identity k zabezpečení zázemí webového rozhraní API pro SPA.

Místo toho, aby rozhraní API backendového serveru zřizovalo cookie ověřování pomocí volání AddIdentityCookies na tvůrce ověřování, rozhraní API serveru nastavuje ověřování nosným tokenem pomocí metody rozšíření AddBearerToken. Zadejte schéma nosných ověřovacích tokenů pomocí IdentityConstants.BearerScheme.

V Backend/Program.cs změňte ověřovací služby a konfiguraci na následující:

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

V BlazorWasmAuth/Identity/CookieAuthenticationStateProvider.cs odstraňte parametr řetězce dotazu useCookies v metodě LoginAsync u CookieAuthenticationStateProvider.

- login?useCookies=true
+ login

V tomto okamžiku musíte zadat vlastní kód pro parsování AccessTokenResponse klienta a správu přístupových a obnovovacích tokenů. Další informace najdete v tématu Použití Identity k zabezpečení zázemí webového rozhraní API pro SPA.

Další Identity scénáře

Scénáře, na které se vztahuje soubor dokumentace:

Informace o dalších Identity scénářích poskytovaných rozhraním API najdete v tématu Použití Identity k zabezpečení back-endu webového rozhraní API pro služby SPA:

  • Zabezpečení vybraných koncových bodů
  • Správa uživatelských informací

Použití zabezpečených ověřovacích toků k zachování citlivých dat a přihlašovacích údajů

Warning

Neukládejte tajné kódy aplikací, připojovací řetězec, přihlašovací údaje, hesla, osobní identifikační čísla (PIN), privátní kód C#/.NET nebo privátní klíče/tokeny v kódu na straně klienta, což je vždy nezabezpečené. V testovacích a produkčních prostředích by měl kód na straně Blazor serveru a webová rozhraní API používat toky zabezpečeného ověřování, které se vyhýbají uchovávání přihlašovacích údajů v kódu projektu nebo konfiguračních souborech. Mimo místní testování vývoje doporučujeme vyhnout se použití proměnných prostředí k ukládání citlivých dat, protože proměnné prostředí nejsou nejbezpečnějším přístupem. Pro místní testování vývoje se pro zabezpečení citlivých dat doporučuje nástroj Secret Manager. Další informace najdete v tématu Bezpečné udržování citlivých dat a přihlašovacích údajů.

Ukázkové aplikace

V tomto článku slouží ukázkové aplikace jako referenční informace pro samostatné Blazor WebAssembly aplikace, které přistupují k ASP.NET Core Identity prostřednictvím back-endového webového rozhraní API. Ukázka obsahuje dvě aplikace:

  • Backend: Aplikace back-endového webového rozhraní API, která udržuje úložiště identit uživatelů pro ASP.NET Core Identity.
  • BlazorWasmAuth: Samostatná Blazor WebAssembly front-endová aplikace s ověřováním uživatelů.

Pomocí následujícího odkazu přejděte k ukázkovým aplikacím prostřednictvím složky nejnovější verze z kořenového adresáře úložiště. Ukázky jsou k dispozici pro .NET 8 nebo novější. Najdete soubor README ve složce BlazorWebAssemblyStandaloneWithIdentity pro postup, jak spustit ukázkové aplikace.

Zobrazení nebo stažení ukázkového kódu (postup stažení)

Balíčky a kód aplikace pro webové API backendu

Back-endová webová aplikace API udržuje úložiště identit uživatelů pro ASP.NET Core Identity.

Packages

Aplikace používá následující balíčky NuGet:

Pokud vaše aplikace používá jiného poskytovatele databáze než poskytovatel v paměti, nevytvářejte ve své aplikaci referenci balíčku pro EF Core.

V souboru projektu aplikace (.csproj) je nakonfigurovaná invariantní globalizace .

Ukázkový kód aplikace

Nastavení aplikace konfiguruje back-endové a front-endové adresy URL:

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

Soubor Backend.http lze použít k testování žádosti o data o počasí. Upozorňujeme, že BlazorWasmAuth aplikace musí být spuštěná, aby otestovala koncový bod, a koncový bod je pevně zakódovaný do souboru. Další informace naleznete v tématu Použití souborů .http v sadě Visual Studio 2022.

Následující nastavení a konfigurace se nacházejí v souboru aplikace Program.

Identita uživatele pomocí ověřování cookie se přidává voláním AddAuthentication a AddIdentityCookies. Služby pro kontroly autorizace jsou přidány voláním AddAuthorizationBuilder.

Doporučuje se pouze pro ukázky; tato aplikace používá poskytovatele databáze v paměti pro registraci kontextu databáze (EF Core). Zprostředkovatel databáze v paměti usnadňuje restartování aplikace a otestování toků registrace a přihlášení uživatelů. Každé spuštění začíná novou databází, ale aplikace obsahuje ukázkový kód testovacího uživatele, který je popsán dále v tomto článku. Pokud se databáze změní na SQLite, uživatelé se ukládají mezi relacemi, ale databázi je potřeba vytvořit prostřednictvím migrací, jak je znázorněno v úvodním EF Core návodu†. Pro produkční kód můžete použít další relační zprostředkovatele, jako je SQL Server.

Note

†Návod EF Core pro začátečníky používá příkazy PowerShellu ke spouštění migrace databáze při použití Visual Studio. Alternativním přístupem v sadě Visual Studio je použití uživatelského rozhraní připojených služeb:

V Průzkumník řešení poklikejte na Připojené služby. V části Závislosti služby> vyberte tři tečky () a poté buď ... pro vytvoření migrace, nebo Aktualizovat databázi pro aktualizaci databáze.

Nakonfigurujte Identity k používání databáze EF Core a k zpřístupnění koncových bodů Identity přes volání na AddIdentityCore, AddEntityFrameworkStores a AddApiEndpoints.

Je zavedena zásada sdílení prostředků mezi zdroji (CORS), která umožňuje žádosti z frontendových a backendových aplikací. Náhradní adresy URL jsou nakonfigurované pro zásady CORS, pokud je nastavení aplikace neposkytuje:

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

Projekt obsahuje balíčky a konfiguraci pro vytváření dokumentů OpenAPI.

Služby a koncové body pro Swagger/OpenAPI jsou součástí dokumentace k webovému rozhraní API a testování vývoje. Další informace o NSwag najdete v tématu Začínáme se službou NSwag a ASP.NET Core.

Deklarace rolí uživatele se odesílají ze minimálního API na /roles koncový bod.

Trasy se mapují pro Identity koncové body voláním MapIdentityApi<AppUser>().

Koncový bod odhlášení (/Logout) je nakonfigurovaný v kanálu middlewaru pro odhlášení uživatelů.

Pokud chcete zabezpečit koncový bod, přidejte do definice trasy metodu RequireAuthorization rozšíření. Pro kontroler přidejte [Authorize] atribut do kontroleru nebo akce.

Další informace o základních vzorech pro inicializaci a konfiguraci DbContext instance naleznete v tématu Životnost, Konfigurace a Inicializace DbContext v EF Core dokumentaci.

Balíčky a kód samostatné aplikace frontendu Blazor WebAssembly

Samostatná Blazor WebAssembly front-endová aplikace předvádí ověřování uživatelů a autorizaci pro přístup k privátní webové stránce.

Packages

Aplikace používá následující balíčky NuGet:

Ukázkový kód aplikace

Složka Models obsahuje modely aplikace:

Rozhraní IAccountManagement (Identity/CookieHandler.cs) poskytuje služby správy účtů.

Třída CookieAuthenticationStateProvider zpracovává stav pro ověřování na základě Identity/CookieAuthenticationStateProvider.cs a poskytuje implementace služby správy účtů popsané rozhraním . Metoda LoginAsync explicitně povolí cookie ověřování prostřednictvím useCookies řetězcové hodnoty truedotazu . Třída také spravuje vytváření nároků na role pro ověřené uživatele.

Třída CookieHandler (Identity/CookieHandler.cs) zajišťuje, že cookie se přihlašovací údaje odesílají s každou žádostí do back-endového webového rozhraní API, které zpracovává Identity a udržuje Identity úložiště dat.

Poskytuje wwwroot/appsettings.file koncové body adresy URL back-endu a front-endu.

Komponenta App zveřejňuje stav ověřování jako kaskádový parametr. Další informace najdete v tématu ASP.NET Core Blazor ověřování a autorizace.

MainLayout komponenta a NavMenu komponenta používají AuthorizeView komponentu k selektivnímu zobrazení obsahu na základě stavu ověřování uživatele.

Následující komponenty zpracovávají běžné úlohy ověřování uživatelů a využívají IAccountManagement služby:

Komponenta PrivatePage (Components/Pages/PrivatePage.razor) vyžaduje ověření a zobrazuje deklarace identity uživatele.

Služby a konfigurace jsou k dispozici v Program souboru (Program.cs):

  • Obslužná rutina cookie je zaregistrovaná jako služba s vymezeným oborem.
  • Autorizační služby jsou zaregistrované.
  • Vlastní zprostředkovatel stavu ověřování je zaregistrovaný jako služba s vymezeným oborem.
  • Rozhraní pro správu účtů (IAccountManagement) je zaregistrované.
  • Základní adresa URL hostitele je nakonfigurovaná pro zaregistrovanou instanci klienta HTTP.
  • Základní URL základního backendu je nakonfigurovaná pro registrovanou instanci klienta HTTP, která se používá k autentizačním interakcím s webovým rozhraním API backendu. Klient HTTP používá obslužnou rutinu cookie k zajištění, že cookie se přihlašovací údaje odesílají s každou žádostí.

Zavolejte AuthenticationStateProvider.NotifyAuthenticationStateChanged, když se změní stav ověřování uživatele. Příklad naleznete v metodách LoginAsync a LogoutAsync třídy CookieAuthenticationStateProvider (Identity/CookieAuthenticationStateProvider.cs).

Warning

Komponenta AuthorizeView selektivně zobrazuje obsah uživatelského rozhraní v závislosti na tom, jestli je uživatel autorizovaný. Veškerý obsah v Blazor WebAssembly rámci aplikace umístěné v komponentě AuthorizeView je zjistitelný bez ověřování, takže po úspěšném ověření by se měl citlivý obsah získat z back-endového webového rozhraní API založeného na serveru. Další informace naleznete v následujících zdrojích:

Testování ukázky počátečního nastavení uživatele

Třída SeedData (SeedData.cs) ukazuje, jak vytvořit testovací uživatele pro vývoj. Testovací uživatel s názvem Leela se přihlásí k aplikaci pomocí e-mailové adresy leela@contoso.com. Heslo uživatele je nastavené na Passw0rd!. Leela má role Administrator a Manager pro autorizaci, které umožňují uživateli přistupovat k manažerské stránce na /private-manager-page, ale ne k editorové stránce na adrese /private-editor-page.

Warning

Nikdy nepovolte spuštění testovacího uživatelského kódu v produkčním prostředí. SeedData.InitializeAsync je volán pouze v Development prostředí v Program souboru:

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

Roles

Deklarace rolí nejsou odesílány zpět z koncového bodu manage/info, aby se vytvořily uživatelské deklarace pro uživatele aplikace BlazorWasmAuth. Deklarace identity rolí se spravují nezávisle prostřednictvím samostatného požadavku v GetAuthenticationStateAsync metodě třídy (CookieAuthenticationStateProvider) po ověření uživatele v Identity/CookieAuthenticationStateProvider.cs projektu.Backend

V CookieAuthenticationStateProvider se vytvoří žádost o role ke koncovému bodu /roles projektu rozhraní API serveru Backend. Odpověď se načte do řetězce voláním ReadAsStringAsync(). JsonSerializer.Deserialize deserializuje řetězec do vlastního RoleClaim pole. Nakonec se nároky přidají do kolekce nároků uživatele.

V souboru rozhraní API serveru , minimalní rozhraní API spravuje koncový bod . Nároky RoleClaimType jsou vybrány jako anonymní typ a serializovány pro návrat do projektu s .

Koncový bod rolí vyžaduje autorizaci voláním RequireAuthorization. Pokud se rozhodnete nepoužívat minimální rozhraní API ve prospěch kontrolerů pro zabezpečené koncové body rozhraní API serveru, nezapomeňte nastavit [Authorize] atribut pro kontrolery nebo akce.

Hostování mezi doménami (konfigurace stejných stránek)

Ukázkové aplikace jsou nakonfigurované pro hostování obou aplikací ve stejné doméně. Pokud hostujete aplikaci Backend na jiné doméně než aplikaci BlazorWasmAuth, odkomentujte kód, který konfiguruje cookie (ConfigureApplicationCookie) v souboru Backend aplikace Program. Výchozí hodnoty jsou:

Změňte hodnoty na:

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

Další informace o nastavení same-site cookie najdete v následujících zdrojích:

Podpora antiforgery

Pouze koncový bod odhlášení (/logout) v aplikaci Backend vyžaduje pozornost, aby se snížila hrozba Cross-Site Request Forgery (CSRF).

Koncový bod odhlášení kontroluje, zda je tělo prázdné, aby se zabránilo CSRF útokům. Vyžadováním těla zprávy musí být požadavek proveden pomocí JavaScriptu, což je jedinou cestou, jak získat přístup k autentizaci cookie. Koncový bod odhlášení není přístupný pomocí post založeného na formuláři. Tím zabráníte škodlivému webu v odhlášení uživatele.

Koncový bod je navíc chráněný autorizací (RequireAuthorization), aby se zabránilo anonymnímu přístupu.

Klientská BlazorWasmAuth aplikace je jednoduše nutná k předání prázdného objektu {} v textu požadavku.

Mimo koncový bod odhlášení je zmírnění antiforgery vyžadováno pouze při odesílání dat formuláře na server kódovaná jako multipart/form-data, text/plain nebo . Blazor ve většině případů spravuje ochranu proti CSRF pro formuláře. Další informace najdete v tématu ASP.NET Core Blazor autentizace a autorizace a přehled formulářů ASP.NET CoreBlazor.

Požadavky na jiné koncové body rozhraní API serveru (webové rozhraní API) s kódovaným obsahem a povoleným application/jsonCORS nevyžadují ochranu CSRF. Proto se pro Backend koncový bod zpracování dat (/data-processing) aplikace nevyžaduje žádná ochrana CSRF. Koncový bod role (/roles) nepotřebuje ochranu CSRF, protože se jedná o koncový bod GET, který neupravuje žádný stav.

Troubleshoot

Logging

Pokud chcete povolit protokolování ladění nebo trasování pro Blazor WebAssembly ověřování, podívejte se na logování v ASP.NET CoreBlazor.

Běžné chyby

Zkontrolujte konfiguraci každého projektu. Ověřte správnost adres URL:

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

Pokud se konfigurace zobrazí správně:

  • Analyzujte protokoly aplikace.

  • Prozkoumejte síťový provoz mezi BlazorWasmAuth aplikací a Backend aplikací pomocí vývojářských nástrojů prohlížeče. Často se po provedení požadavku klientovi vrátí přesná chybová zpráva nebo zpráva s povědomím o příčině problému. Pokyny k vývojářským nástrojům najdete v následujících článcích:

  • Google Chrome (dokumentace Google)

  • Microsoft Edge

  • Mozilla Firefox (dokumentace k Mozilla)

Tým dokumentace reaguje na zpětnou vazbu a chyby v článcích. Otevřete problém pomocí odkazu Otevřít problém s dokumentací v dolní části článku. Tým nemůže poskytovat podporu produktů. K dispozici je několik veřejných fór podpory, která vám pomůžou s řešením potíží s aplikací. Doporučujeme následující:

Předchozí fóra nejsou vlastněna ani řízena Společností Microsoft.

V případě nezabezpečených, necitlivých a nekonfidenčních reprodukovatelných zpráv o chybách rámce otevřete hlášení u produktové jednotky ASP.NET Core. Neotevírejte problém s produktovou jednotkou, dokud důkladně neprošetříte příčinu problému a nemůžete ho vyřešit sami a s pomocí komunity na veřejném fóru podpory. Produktová jednotka nedokáže řešit potíže s jednotlivými aplikacemi, které jsou poškozené kvůli jednoduché chybné konfiguraci nebo případům použití zahrnujícím služby třetích stran. Pokud je zpráva svou povahou citlivá nebo důvěrná nebo popisuje potenciální chybu zabezpečení v produktu, kterou mohou kyberútočníci zneužít, přečtěte si téma Hlášení problémů se zabezpečením a chyb (dotnet/aspnetcore úložiště GitHub).

Soubory cookie a data webu

Soubory cookie a data webu se můžou uchovávat v aktualizacích aplikací a kolidovat s testováním a odstraňováním potíží. Při provádění změn kódu aplikace, změn uživatelského účtu nebo změn konfigurace aplikace zrušte zaškrtnutí následujících pokynů:

  • Soubory cookie přihlašování uživatelů
  • Soubory cookie aplikace
  • Uložená a uložená data lokality v mezipaměti

Jedním z přístupů k tomu, aby se zabránilo zasahování souborů cookie a dat webu do testování a řešení potíží, je:

  • Konfigurace prohlížeče
    • K testování můžete použít prohlížeč, který můžete nakonfigurovat tak, aby při každém zavření prohlížeče odstranil všechna cookie data a data webu.
    • Ujistěte se, že je prohlížeč zavřený buď ručně, nebo automaticky podle integrovaného vývojového prostředí (IDE) při každé změně aplikace, testovacího uživatele nebo konfigurace poskytovatele.
  • Pomocí vlastního příkazu otevřete prohlížeč v režimu InPrivate nebo Incognito v sadě Visual Studio:
    • Otevřete dialogové okno Procházet z tlačítka Spustit v sadě Visual Studio.
    • Vyberte tlačítko Přidat.
    • Do pole Program zadejte cestu k prohlížeči. Následující spustitelné cesty jsou typická umístění instalace pro Windows 10. Pokud je váš prohlížeč nainstalovaný v jiném umístění nebo nepoužíváte Windows 10, zadejte cestu ke spustitelnému souboru prohlížeče.
      • 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
    • V poli Argumenty zadejte možnost příkazového řádku, kterou prohlížeč používá k otevření v režimu InPrivate nebo Anonymní režim. Některé prohlížeče vyžadují adresu URL aplikace.
      • Microsoft Edge: Použijte -inprivate.
      • Google Chrome: Použijte --incognito --new-window {URL}, kde {URL} je zástupný symbol pro adresu URL, kterou chcete otevřít (například https://localhost:5001).
      • Mozilla Firefox: Použijte -private -url {URL}, kde {URL} zástupný znak je adresa URL k otevření, například https://localhost:5001.
    • Do pole Uživatelsky přívětivý název zadejte název. Například Firefox Auth Testing.
    • Vyberte tlačítko OK.
    • Pokud se chcete vyhnout výběru profilu prohlížeče pro každou iteraci testování pomocí aplikace, nastavte profil jako výchozí tlačítkem Nastavit jako výchozí .
    • Ujistěte se, že integrované vývojové prostředí (IDE) zavře prohlížeč při jakékoliv změně aplikace, testovacího uživatele nebo konfigurace poskytovatele.

Upgrady aplikací

Funkční aplikace může selhat okamžitě po upgradu sady .NET SDK na vývojovém počítači nebo změně verzí balíčků v aplikaci. V některých případech můžou inkoherentní balíčky přerušit aplikaci při provádění hlavních upgradů. Většinu těchto problémů je možné vyřešit pomocí těchto pokynů:

  1. Vymažte mezipaměti balíčků NuGet místního systému spuštěním dotnet nuget locals all --clear z příkazového prostředí.
  2. Odstraňte složky projektu bin a obj.
  3. Obnovte a znovu sestavte projekt.
  4. Před opětovným nasazením aplikace odstraňte všechny soubory ve složce nasazení na serveru.

Note

Použití verzí balíčků nekompatibilních s cílovou architekturou aplikace se nepodporuje. Informace o balíčku najdete v galerii NuGet.

Zkontrolujte nároky uživatele

Při řešení problémů s deklaracemi identity uživatelů je možné použít následující UserClaims komponentu přímo v aplikacích nebo sloužit jako základ pro další přizpůsobení.

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

Dodatečné zdroje

  • Last updated on