chroniony magazyn przeglądarki ASP.NET Core Blazor

W przypadku danych przejściowych, które użytkownik aktywnie tworzy, często używaną lokalizacją magazynu są kolekcje localStorage i sessionStorage przeglądarki.

• localStorage jest powiązana z instancją przeglądarki. Jeśli użytkownik ponownie załaduje stronę lub zamknie i ponownie otworzy przeglądarkę, stan będzie się powtarzać. Jeśli użytkownik otworzy wiele kart przeglądarki, stan będzie współdzielony we wszystkich kartach. Dane są utrwalane localStorage do momentu jawnego wyczyszczenia. Dane localStorage dokumentu załadowane w sesji "przeglądania prywatnego" lub "trybie incognito" są czyszczone po zamknięciu ostatniej karty "prywatnej".
• sessionStorage jest ograniczona do karty przeglądarki. Jeśli użytkownik ponownie załaduje kartę, stan będzie się powtarzać. Jeśli użytkownik zamknie kartę lub przeglądarkę, stan zostanie utracony. Jeśli użytkownik otworzy wiele kart przeglądarki, każda karta ma własną niezależną wersję danych.

Ogólnie rzecz biorąc, sessionStorage jest bezpieczniejszy do użycia. sessionStorage pozwala uniknąć ryzyka, że użytkownik otwiera wiele kart i napotyka następujące elementy:

• Usterki w przechowywaniu stanu w zakładkach.
• Mylące zachowanie, gdy karta zastępuje stan innych kart.

localStorage jest lepszym wyborem, jeśli aplikacja musi zachować stan podczas zamykania i ponownego otwierania przeglądarki.

Zastrzeżenia dotyczące korzystania z pamięci przeglądarki:

• Podobnie jak w przypadku korzystania z bazy danych po stronie serwera, ładowanie i zapisywanie danych jest asynchroniczne.
• Żądana strona nie istnieje w przeglądarce podczas prerenderingu, więc magazyn lokalny nie jest dostępny podczas prerenderingu.
• Przechowywanie kilku kilobajtów danych jest uzasadnione dla aplikacji po stronie serwera Blazor. Poza kilkoma kilobajtami należy wziąć pod uwagę implikacje dotyczące wydajności, ponieważ dane są ładowane i zapisywane w sieci.
• Użytkownicy mogą wyświetlać lub modyfikować dane. ASP.NET Core Data Protection może ograniczyć ryzyko. Na przykład ASP.NET Core Protected Browser Storage używa ASP.NET Core Data Protection.

Pakiety NuGet innych firm udostępniają interfejsy API do pracy z localStorage i sessionStorage. Warto rozważyć wybranie pakietu, który w sposób niewidoczny używa ASP.NET Core Data Protection. Usługa Data Protection szyfruje przechowywane dane i zmniejsza potencjalne ryzyko naruszenia przechowywanych danych. Jeśli dane serializowane w formacie JSON są przechowywane w postaci zwykłego tekstu, użytkownicy mogą wyświetlać dane przy użyciu narzędzi deweloperskich przeglądarki, a także modyfikować przechowywane dane. Zabezpieczanie danych trywialnych nie jest problemem. Na przykład odczytywanie lub modyfikowanie przechowywanego koloru elementu interfejsu użytkownika nie jest istotnym zagrożeniem bezpieczeństwa dla użytkownika lub organizacji. Unikaj zezwalania użytkownikom na inspekcję lub manipulowanie poufnymi danymi.

Ochrona pamięci przeglądarki w ASP.NET Core

ASP.NET Core Protected Browser Storage korzysta z usługi ASP.NET Core Data Protection dla localStorage i sessionStorage.

Zapisywanie i ładowanie danych w składniku

W każdym składniku, który wymaga ładowania lub zapisywania danych w magazynie przeglądarki, użyj dyrektywy @inject, aby wstrzyknąć wystąpienie jednego z następujących:

• ProtectedLocalStorage
• ProtectedSessionStorage

Wybór zależy od lokalizacji przechowywania przeglądarki, której chcesz użyć. W poniższym przykładzie sessionStorage jest używany:

@using Microsoft.AspNetCore.Components.Server.ProtectedBrowserStorage
@inject ProtectedSessionStorage ProtectedSessionStore

@using Microsoft.AspNetCore.ProtectedBrowserStorage
@inject ProtectedSessionStorage ProtectedSessionStore

Dyrektywę @using można umieścić w pliku aplikacji _Imports.razor zamiast w składniku. _Imports.razor Użycie pliku sprawia, że przestrzeń nazw jest dostępna dla większych segmentów aplikacji lub całej aplikacji.

Aby zachować wartość currentCount w składniku Counter aplikacji na podstawie szablonu projektu Blazor, zmodyfikuj metodę IncrementCount, aby użyć ProtectedSessionStore.SetAsync.

private async Task IncrementCount()
{
    currentCount++;
    await ProtectedSessionStore.SetAsync("count", currentCount);
}

W większych, bardziej realistycznych aplikacjach przechowywanie poszczególnych pól jest mało prawdopodobne. Aplikacje częściej przechowują całe obiekty modelu, które obejmują złożony stan. ProtectedSessionStore automatycznie serializuje i deserializuje dane JSON w celu przechowywania złożonych obiektów stanu.

W poprzednim przykładzie kodu, dane currentCount są przechowywane jako sessionStorage['count'] w przeglądarce użytkownika. Dane nie są przechowywane w postaci zwykłego tekstu, ale są chronione przy użyciu ASP.NET Core Data Protection. Zaszyfrowane dane można sprawdzić, jeśli sessionStorage['count'] jest oceniany w konsoli programisty przeglądarki.

Aby odzyskać dane currentCount, gdy użytkownik powróci do składnika Counter, nawet jeśli znajduje się w nowym okręgu, użyj ProtectedSessionStore.GetAsync.

protected override async Task OnInitializedAsync()
{
    var result = await ProtectedSessionStore.GetAsync<int>("count");
    currentCount = result.Success ? result.Value : 0;
}

protected override async Task OnInitializedAsync()
{
    currentCount = await ProtectedSessionStore.GetAsync<int>("count");
}

Jeśli parametry składnika obejmują stan nawigacji, wywołaj ProtectedSessionStore.GetAsync i przypisz wynik w null inny niż OnParametersSetAsync, a nie w OnInitializedAsync. OnInitializedAsync jest wywoływany tylko raz, gdy składnik jest najpierw instancjonowany. OnInitializedAsync nie zostanie ponownie wywołana później, jeśli użytkownik przejdzie do innego adresu URL, pozostając na tej samej stronie. Aby uzyskać więcej informacji, zobacz Cykl życia składników platformy ASP.NET Core Razor.

Obsługa stanu ładowania

Ponieważ dostęp do magazynu przeglądarki jest uzyskiwany asynchronicznie za pośrednictwem połączenia sieciowego, zawsze istnieje okres czasu przed załadowaniem i udostępnieniem danych składnikowi. Aby uzyskać najlepsze wyniki, zamiast wyświetlania pustych lub domyślnych danych, renderuj komunikat podczas trwania ładowania.

private int? currentCount;

@if (currentCount.HasValue)
{
    <p>Current count: <strong>@currentCount</strong></p>
    <button @onclick="IncrementCount">Increment</button>
}
else
{
    <p>Loading...</p>
}

Obsługa prerenderingu

Podczas prerenderingu:

• Interakcyjne połączenie z przeglądarką użytkownika nie istnieje.
• Przeglądarka nie ma jeszcze strony, na której można uruchomić kod JavaScript.

localStorage lub sessionStorage nie są dostępne podczas prerenderingu. Jeśli składnik próbuje wchodzić w interakcję z pamięcią, zostanie wygenerowany błąd wyjaśniający, że nie można wydać wywołań interop w JavaScript, ponieważ składnik jest prerenderowany.

Jednym ze sposobów usunięcia błędu jest wyłączenie prerenderingu. Zazwyczaj jest to najlepszy wybór, jeśli aplikacja intensywnie korzysta z magazynu przechowywania danych opartego na przeglądarce. Wstępne renderowanie zwiększa złożoność i nie przynosi korzyści aplikacji, ponieważ nie może ona wstępnie wyrenderować żadnej użytecznej zawartości, dopóki localStorage lub sessionStorage nie będą dostępne.

<Routes @rendermode="new InteractiveServerRenderMode(prerender: false)" />

<HeadOutlet @rendermode="new InteractiveServerRenderMode(prerender: false)" />

<component type="typeof(App)" render-mode="Server" />

Wstępne przetwarzanie może być przydatne w przypadku innych stron, które nie używają localStorage ani sessionStorage. Aby zachować wstępne ładowanie, odrocz operację ładowania, dopóki przeglądarka nie zostanie połączona z obwodem. Poniżej przedstawiono przykład przechowywania wartości licznika:

@using Microsoft.AspNetCore.Components.Server.ProtectedBrowserStorage
@inject ProtectedLocalStorage ProtectedLocalStore

@if (isConnected)
{
    <p>Current count: <strong>@currentCount</strong></p>
    <button @onclick="IncrementCount">Increment</button>
}
else
{
    <p>Loading...</p>
}

@code {
    private int currentCount;
    private bool isConnected;

    protected override async Task OnAfterRenderAsync(bool firstRender)
    {
        if (firstRender)
        {
            isConnected = true;
            await LoadStateAsync();
            StateHasChanged();
        }
    }

    private async Task LoadStateAsync()
    {
        var result = await ProtectedLocalStore.GetAsync<int>("count");
        currentCount = result.Success ? result.Value : 0;
    }

    private async Task IncrementCount()
    {
        currentCount++;
        await ProtectedLocalStore.SetAsync("count", currentCount);
    }
}

@using Microsoft.AspNetCore.ProtectedBrowserStorage
@inject ProtectedLocalStorage ProtectedLocalStore

@if (isConnected)
{
    <p>Current count: <strong>@currentCount</strong></p>
    <button @onclick="IncrementCount">Increment</button>
}
else
{
    <p>Loading...</p>
}

@code {
    private int currentCount = 0;
    private bool isConnected = false;

    protected override async Task OnAfterRenderAsync(bool firstRender)
    {
        if (firstRender)
        {
            isConnected = true;
            await LoadStateAsync();
            StateHasChanged();
        }
    }

    private async Task LoadStateAsync()
    {
        currentCount = await ProtectedLocalStore.GetAsync<int>("count");
    }

    private async Task IncrementCount()
    {
        currentCount++;
        await ProtectedLocalStore.SetAsync("count", currentCount);
    }
}

Uwzględnianie zachowania stanu dla wspólnego dostawcy

Jeśli wiele składników korzysta z magazynu opartego na przeglądarce, implementowanie kodu dostawcy stanu wiele razy powoduje duplikowanie kodu. Jedną z opcji unikania duplikowania kodu jest utworzenie składnika nadrzędnego dostawcy stanu, który hermetyzuje logikę dostawcy stanu. Składniki podrzędne mogą pracować z utrwalanymi danymi bez względu na mechanizm trwałości stanu.

W poniższym przykładzie składnika CounterStateProvider dane licznika są zapisywane do sessionStorage, a faza ładowania jest obsługiwana poprzez nierealizowanie renderowania zawartości podrzędnej do zakończenia ładowania stanu.

Składnik CounterStateProvider zajmuje się prerenderowaniem, nie ładując stanu aż do momentu po renderowaniu składnika w metodzie cyklu życia OnAfterRenderAsync, która nie jest wykonywana podczas prerenderowania.

Podejście opisane w tej sekcji nie jest w stanie wyzwolić ponownego renderowania wielu związanych komponentów na tej samej stronie. Jeśli jeden z subskrybowanych składników zmienia stan, ponownie się renderuje i może wyświetlać zaktualizowany stan, natomiast inny składnik na tej samej stronie, wyświetlający ten stan, pokazuje nieaktualne dane do czasu swojego kolejnego ponownego renderowania. W związku z tym podejście opisane w tej sekcji najlepiej nadaje się do używania stanu w jednym składniku na stronie.

CounterStateProvider.razor:

@using Microsoft.AspNetCore.Components.Server.ProtectedBrowserStorage
@inject ProtectedSessionStorage ProtectedSessionStore

@if (isLoaded)
{
    <CascadingValue Value="this">
        @ChildContent
    </CascadingValue>
}
else
{
    <p>Loading...</p>
}

@code {
    private bool isLoaded;

    [Parameter]
    public RenderFragment? ChildContent { get; set; }

    public int CurrentCount { get; set; }

    protected override async Task OnAfterRenderAsync(bool firstRender)
    {
        if (firstRender)
        {
            isLoaded = true;
            await LoadStateAsync();
            StateHasChanged();
        }
    }

    private async Task LoadStateAsync()
    {
        var result = await ProtectedSessionStore.GetAsync<int>("count");
        CurrentCount = result.Success ? result.Value : 0;
        isLoaded = true;
    }

    public async Task IncrementCount()
    {
        CurrentCount++;
        await ProtectedSessionStore.SetAsync("count", CurrentCount);
    }
}

@using Microsoft.AspNetCore.ProtectedBrowserStorage
@inject ProtectedSessionStorage ProtectedSessionStore

@if (isLoaded)
{
    <CascadingValue Value="this">
        @ChildContent
    </CascadingValue>
}
else
{
    <p>Loading...</p>
}

@code {
    private bool isLoaded;

    [Parameter]
    public RenderFragment ChildContent { get; set; }

    public int CurrentCount { get; set; }

    protected override async Task OnAfterRenderAsync(bool firstRender)
    {
        if (firstRender)
        {
            isLoaded = true;
            await LoadStateAsync();
            StateHasChanged();
        }
    }

    private async Task LoadStateAsync()
    {
        CurrentCount = await ProtectedSessionStore.GetAsync<int>("count");
        isLoaded = true;
    }

    public async Task IncrementCount()
    {
        CurrentCount++;
        await ProtectedSessionStore.SetAsync("count", CurrentCount);
    }
}

<Routes @rendermode="InteractiveServer" />

<CounterStateProvider>
    <Router ...>
        ...
    </Router>
</CounterStateProvider>

Zawinięte składniki odbierają i mają możliwość modyfikacji stanu utrwalonego licznika. Następujący Counter składnik implementuje wzorzec:

@page "/counter"

<p>Current count: <strong>@CounterStateProvider?.CurrentCount</strong></p>
<button @onclick="IncrementCount">Increment</button>

@code {
    [CascadingParameter]
    private CounterStateProvider? CounterStateProvider { get; set; }

    private async Task IncrementCount()
    {
        if (CounterStateProvider is not null)
        {
            await CounterStateProvider.IncrementCount();
        }
    }
}

Poprzedni składnik nie jest wymagany do interakcji z ProtectedBrowserStorage, ani nie uczestniczy w fazie "ładowania".

Ogólnie rzecz biorąc, zalecany jest wzorzec składnika nadrzędnego dostawcy stanu:

• Aby korzystać ze stanu w wielu komponentach.
• Jeśli istnieje tylko jeden obiekt stanu najwyższego poziomu do przechowywania.

Aby zachować wiele różnych obiektów stanu i wykorzystywać różne podzbiory obiektów w różnych miejscach, lepiej unikać globalnego zachowywania stanu.