ASP.NET Core Blazor Progressive Web Application (PWA)

Un'applicazione Blazor Web progressiva (PWA) è un'applicazione a pagina singola che usa API e funzionalità moderne del browser per comportarsi come un'app desktop.

Blazor WebAssembly è una piattaforma di app Web sul lato client basata su standard, in modo che possa usare qualsiasi API del browser, incluse le API PWA necessarie per le funzionalità seguenti:

• Lavorare offline e caricare immediatamente, indipendentemente dalla velocità di rete.
• In esecuzione nella propria finestra dell'app, non solo in una finestra del browser.
• Avviato dal menu Start del sistema operativo dell'host, dal dock o dalla schermata iniziale.
• Ricezione di notifiche push da un server back-end, anche se l'utente non usa l'app.
• Aggiornamento automatico in corso in il background.

La parola progressive viene usata per descrivere queste app perché:

• Un utente potrebbe prima scoprire e usare l'app nel browser web come qualsiasi altra SPA.
• Successivamente, l'utente procede all'installazione nel sistema operativo e abilita le notifiche push.

Creare un progetto dal modello PWA

Visual Studio

Quando si crea una nuova Blazor WebAssembly app, selezionare la casella di controllo Applicazione Web Progressiva.

Visual Studio Code / CLI di .NET

Usa il seguente comando per creare un progetto PWA in un'interfaccia a riga di comando con l'opzione --pwa.

dotnet new blazorwasm -o MyBlazorPwa --pwa

Nel comando precedente l'opzione -o|--output crea una nuova cartella per l'app denominata MyBlazorPwa.

Convertire un'app esistente Blazor WebAssembly in una PWA

Convertire un'app esistente Blazor WebAssembly in PWA seguendo le istruzioni riportate in questa sezione.

Nel file di progetto dell'app:

• Aggiungere la proprietà seguente ServiceWorkerAssetsManifest a un oggetto PropertyGroup:

    ...
    <ServiceWorkerAssetsManifest>service-worker-assets.js</ServiceWorkerAssetsManifest>
  </PropertyGroup>
  

• Aggiungere l'elemento seguente ServiceWorker a un oggetto ItemGroup:

  <ItemGroup>
    <ServiceWorker Include="wwwroot\service-worker.js" 
      PublishedContent="wwwroot\service-worker.published.js" />
  </ItemGroup>
  

Per ottenere asset statici, usare uno degli approcci seguenti:

• Crea un nuovo progetto PWA separato con il comando dotnet new in un prompt dei comandi.

  dotnet new blazorwasm -o MyBlazorPwa --pwa
  

  Nel comando precedente l'opzione -o|--output crea una nuova cartella per l'app denominata MyBlazorPwa.

  Se non stai convertendo un'app per l'ultimo rilascio, utilizza l'opzione -f|--framework. L'esempio seguente crea l'app per .NET 5:

  dotnet new blazorwasm -o MyBlazorPwa --pwa -f net5.0
  

• Navigare al repository GitHub di ASP.NET Core all'URL seguente, che collega alla origine di riferimento e agli asset del ramo main. Seleziona la versione con cui stai lavorando dall'elenco a discesa Cambia rami o tag applicabile alla tua app.

  Blazor WebAssembly Cartella del modello wwwroot di progetto (dotnet/aspnetcore ramo del repository main GitHub)

  Nota

  In genere, i collegamenti della documentazione alla sorgente di riferimento .NET caricano il ramo predefinito del repository, che rappresenta lo sviluppo corrente per la versione successiva di .NET. Per selezionare un tag per una versione specifica, utilizzare il menu a tendina Seleziona rami o tag. Per altre informazioni, vedere How to select a version tag of ASP.NET Core source code (dotnet/AspNetCore.Docs #26205) (Come selezionare un tag di versione del codice sorgente di ASP.NET - dotnet/AspNetCore.Docs #26205).

  Dalla cartella di origine wwwroot nell'app creata o dagli asset di riferimento nel dotnet/aspnetcore repository GitHub copiare i file seguenti nella cartella dell'app wwwroot :

  • icon-192.png
  • icon-512.png
  • manifest.webmanifest
  • service-worker.js
  • service-worker.published.js

Nel file dell'app wwwroot/index.html :

• Aggiungere <link> elementi per il manifesto e l'icona dell'app:

  <link href="manifest.webmanifest" rel="manifest" />
  <link rel="apple-touch-icon" sizes="512x512" href="icon-512.png" />
  <link rel="apple-touch-icon" sizes="192x192" href="icon-192.png" />
  

• Aggiungere il tag seguente <script> all'interno del tag di chiusura </body> immediatamente dopo il blazor.webassembly.js tag script:

      ...
      <script>navigator.serviceWorker.register('service-worker.js');</script>
  </body>
  

Installazione e manifesto dell'app

Quando si visita un'app creata usando il modello PWA, gli utenti hanno la possibilità di installare l'app nel menu Start, nel dock o nella schermata iniziale del sistema operativo. La modalità di presentazione di questa opzione dipende dal browser dell'utente. Quando si usano browser basati su Chromium desktop, ad esempio Edge o Chrome, viene visualizzato un pulsante Aggiungi nella barra degli URL. Dopo aver selezionato il pulsante Aggiungi , l'utente riceve una finestra di dialogo di conferma:

In iOS, i visitatori possono installare pwa usando il pulsante Condividi di Safari e la relativa opzione Aggiungi a schermata iniziale. In Chrome per Android gli utenti devono selezionare il pulsante Menu nell'angolo in alto a destra, seguito da Aggiungi alla Home schermata.

Dopo l'installazione, l'app viene visualizzata nella propria finestra senza una barra degli indirizzi:

Per personalizzare il titolo, la combinazione di colori, l'icona o altri dettagli della finestra, vedere il manifest.json file nella directory del wwwroot progetto. Lo schema di questo file è definito dagli standard Web. Per ulteriori informazioni, vedere MDN Web Docs: Web App Manifest.

Supporto offline

Le app create con l'opzione modello PWA supportano l'esecuzione offline. Un utente deve prima visitare l'app mentre è online. Il browser scarica e memorizza nella cache automaticamente tutte le risorse necessarie per funzionare offline.

Importante

Il supporto dello sviluppo interferisce con il normale ciclo di sviluppo di apportare modifiche e testarle. Pertanto, il supporto offline è abilitato solo per le app pubblicate .

Avviso

Se si intende distribuire un PWA abilitato per la modalità offline, sono presenti diversi avvisi e avvertenze importanti. Questi scenari sono intrinseci di PWA offline e non specifici di Blazor. Assicurarsi di leggere e comprendere queste avvertenze prima di fare ipotesi sul funzionamento dell'app abilitata per la modalità offline.

Per informazioni sul funzionamento del supporto offline:

1. Pubblica l'app. Per altre informazioni, vedere Ospitare e distribuire ASP.NET Core Blazor.

2. Distribuire l'app in un server che supporta HTTPS e accedere all'app in un browser all'indirizzo HTTPS sicuro.

3. Aprire gli strumenti di sviluppo del browser e verificare che un ruolo di lavoro del servizio sia registrato per l'host nella scheda Applicazione :

   

4. Ricarica la pagina ed esamina la scheda Rete. Service Worker o cache di memoria sono elencati come origini per tutti gli asset della pagina:

   

5. Per verificare che il browser non sia dipendente dall'accesso alla rete per caricare l'app, eseguire le operazioni seguenti:

   • Spegni il server web e osserva come l'app continua a funzionare normalmente, compresi i ricaricamenti di pagina. Analogamente, l'app continua a funzionare normalmente quando è presente una connessione di rete lenta.
   • Indicare al browser di simulare la modalità offline nella scheda Rete :

   

Il supporto offline con un service worker è uno standard Web, non specifico di Blazor. Per ulteriori informazioni sui service worker, vedere la Documentazione Web MDN: Service Worker API. Per altre informazioni sui modelli di utilizzo comuni per i ruoli di lavoro dei servizi, vedere Google Web: The Service Worker Lifecycle(Ciclo di vita del ruolo di lavoro del servizio).

BlazorIl modello di PWA produce due file di lavoro del servizio:

• wwwroot/service-worker.js, che viene utilizzato durante lo sviluppo.
• wwwroot/service-worker.published.js, che viene usato dopo la pubblicazione dell'app.

Per condividere la logica tra i due file dei service worker, considera il seguente approccio:

• Aggiungere un terzo file JavaScript per contenere la logica comune.
• Usare self.importScripts per caricare la logica comune in entrambi i file dei service worker.

Strategia di recupero 'cache-first'

Il service worker integrato del service-worker.published.js risolve le richieste usando una strategia cache-first. Ciò significa che il service worker preferisce restituire il contenuto memorizzato nella cache, indipendentemente dal fatto che l'utente abbia accesso alla rete o che contenuti più recenti siano disponibili sul server.

La strategia cache-first è utile perché:

• Garantisce l'affidabilità. L'accesso alla rete non è uno stato booleano. Un utente non è semplicemente online o offline:

  • Il dispositivo dell'utente può presupporre che sia online, ma la rete potrebbe essere così lenta da essere poco pratica da attendere.
  • La rete potrebbe restituire risultati non validi per determinati URL, ad esempio quando è presente un portale WIFI captive che attualmente blocca o reindirizza determinate richieste.

  Per questo motivo, l'API del navigator.onLine browser non è affidabile e non dovrebbe essere utilizzata.

• Garantisce la correttezza. Quando si compila una cache di risorse offline, il service worker usa l'hashing del contenuto per garantire che abbia recuperato uno snapshot completo e autosufficiente delle risorse in un unico istante. Questa cache viene quindi usata come unità atomica. Non è necessario chiedere alla rete le risorse più recenti, perché le uniche versioni necessarie sono quelle già memorizzate nella cache. Tentare di usare versioni di assembly .NET non compilati insieme rischia di causare incoerenza e incompatibilità.

Se è necessario impedire al browser di recuperare service-worker-assets.js dalla cache HTTP, ad esempio per risolvere gli errori di controllo dell'integrità temporanei durante la distribuzione di una nuova versione del ruolo di lavoro del servizio, aggiornare la registrazione del ruolo di lavoro del servizio in wwwroot/index.html con updateViaCache impostato su 'none':

<script>
  navigator.serviceWorker.register('/service-worker.js', {updateViaCache: 'none'});
</script>

Aggiornamenti sullo sfondo

Come modello mentale, puoi immaginare un PWA offline che si comporti come un'app per dispositivi mobili che può essere installata. L'app viene avviata immediatamente indipendentemente dalla connettività di rete, ma la logica dell'app installata proviene da uno snapshot temporizzato che potrebbe non essere la versione più recente.

Il Blazor modello PWA produce app che tentano automaticamente di aggiornarsi in background ogni volta che l'utente visita e ha una connessione di rete funzionante. Il modo in cui funziona è il seguente:

• Durante la compilazione, il progetto genera un manifesto degli asset del service worker, denominato service-worker-assets.js. Il manifesto elenca tutte le risorse statiche richieste dall'app per funzionare offline, ad esempio assembly .NET, file JavaScript e CSS, inclusi gli hash del contenuto. L'elenco di risorse viene caricato dal service worker in modo che sappia quali risorse mettere in cache.
• Ogni volta che l'utente visita l'app, il browser richiede nuovamente service-worker.js e service-worker-assets.js in background. I file vengono confrontati byte per byte con il service worker installato esistente. Se il server restituisce contenuto modificato per uno di questi file, il service worker tenta di installare una nuova versione di se stesso.
• Quando si installa una nuova versione di se stesso, il service worker crea una nuova cache separata per le risorse offline e inizia a riempire la cache con le risorse elencate in service-worker-assets.js. Questa logica viene implementata nella funzione onInstall all'interno di service-worker.published.js.
• Il processo viene completato correttamente quando tutte le risorse vengono caricate senza errori e tutti gli hash di contenuto corrispondono. In caso di esito positivo, il nuovo service worker entra in uno stato di attesa per l'attivazione. Non appena l'utente chiude l'app (nessuna scheda o finestra dell'app rimane aperta), il nuovo service worker diventa attivo e viene utilizzato per le visite successive all'app. Il service worker precedente e la relativa cache vengono eliminati.
• Se il processo non viene completato correttamente, la nuova istanza del service worker viene scartata. Il processo di aggiornamento viene provato di nuovo nella visita successiva dell'utente, quando si spera che il client disponga di una connessione di rete migliore in grado di completare le richieste.

Personalizzare questo processo modificando la logica del service worker. Nessuno dei comportamenti precedenti è specifico di Blazor, ma piuttosto è semplicemente l'esperienza predefinita fornita dall'opzione del modello PWA. Per ulteriori informazioni, vedere MDN Web Docs: API dei Service Worker.

Come vengono risolte le richieste

Come descritto nella sezione Strategia di recupero cache-first, il service worker predefinito usa una strategia cache-first, ovvero tenta di fornire il contenuto memorizzato nella cache quando disponibile. Se non è presente contenuto memorizzato nella cache per un determinato URL, ad esempio quando si richiedono dati da un'API back-end, il service worker ricorre a una richiesta di rete standard. La richiesta di rete ha esito positivo se il server è raggiungibile. Questa logica viene implementata nella funzione onFetch all'interno di service-worker.published.js.

Se i componenti dell'app si basano sulla richiesta di dati dalle API back-end e si vuole offrire un'esperienza utente semplice per le richieste non riuscite a causa dell'indisponibilità della Razor rete, implementare la logica all'interno dei componenti dell'app. Ad esempio, usa try/catch intorno alle richieste HttpClient.

Supportare le pagine di cui è stato eseguito il rendering nel server

Considerare cosa accade quando l'utente passa per la prima volta a un URL, /counter ad esempio o a qualsiasi altro collegamento diretto nell'app. In questi casi, non si vuole restituire il contenuto memorizzato nella cache come /counter, ma è necessario che il browser carichi il contenuto memorizzato nella cache come /index.html per avviare l'app Blazor WebAssembly. Queste richieste iniziali sono note come richieste di spostamento , anziché:

• subresource richieste di immagini, fogli di stile o altri file.
• fetch/XHR richieste di dati API.

Il service worker predefinito contiene una logica speciale per le richieste di navigazione. Il service worker risolve le richieste restituendo il contenuto memorizzato nella cache per /index.html, indipendentemente dall'URL richiesto. Questa logica viene implementata nella funzione onFetch all'interno di service-worker.published.js.

Se l'app dispone di determinati URL che devono restituire codice HTML eseguito dal server e non devono essere serviti dalla cache /index.html, è necessario modificare la logica nel service worker. Se tutti gli URL contenenti /Identity/ devono essere gestiti come normali richieste solo online al server, modificare la service-worker.published.jsonFetch logica. Individuare il seguente codice:

const shouldServeIndexHtml = event.request.mode === 'navigate';

Modificare il codice come illustrato di seguito:

const shouldServeIndexHtml = event.request.mode === 'navigate'
  && !event.request.url.includes('/Identity/');

Se non esegui questa operazione, indipendentemente dalla connettività di rete, il service worker intercetta le richieste per tali URL e le risolve usando /index.html.

Aggiungere ulteriori endpoint per i provider di autenticazione esterni alla verifica. Nell'esempio seguente, /signin-google per l'autenticazione di Google viene aggiunto al controllo:

const shouldServeIndexHtml = event.request.mode === 'navigate'
  && !event.request.url.includes('/Identity/')
  && !event.request.url.includes('/signin-google');

Non è necessaria alcuna azione per l'ambiente Development , in cui il contenuto viene sempre recuperato dalla rete.

Gestire la cache degli asset

Se il progetto definisce la ServiceWorkerAssetsManifest proprietà MSBuild, gli strumenti di compilazione di Blazor generano un manifesto degli asset del service worker con il nome specificato. Il modello PWA predefinito produce un file di progetto contenente la proprietà seguente:

<ServiceWorkerAssetsManifest>service-worker-assets.js</ServiceWorkerAssetsManifest>

Il file viene inserito nella wwwroot directory di output, in modo che il browser possa recuperare il file richiedendo /service-worker-assets.js. Per visualizzare il contenuto di questo file, aprire /bin/Debug/{TARGET FRAMEWORK}/wwwroot/service-worker-assets.js in un editor di testo. Tuttavia, non modificare il file, perché viene rigenerato in ogni compilazione.

Il manifesto elenca:

• Qualsiasi Blazorrisorse gestite, come gli assembly .NET e i file di runtime .NET WebAssembly necessari per funzionare offline.
• Tutte le risorse per la pubblicazione nella directory dell'app wwwroot , ad esempio immagini, fogli di stile e file JavaScript, inclusi gli asset Web statici forniti da progetti esterni e pacchetti NuGet.

È possibile controllare quali di queste risorse vengono recuperate e memorizzate nella cache dal service worker modificando la logica di onInstall in service-worker.published.js. Il service worker recupera e memorizza nella cache i file che corrispondono alle tipiche estensioni di file Web, come .html, .css, .js e .wasm, oltre ai tipi di file specifici di Blazor WebAssembly, come i file .pdb (tutte le versioni) e i file .dll (ASP.NET Core in .NET 7 o versioni precedenti).

Per includere risorse aggiuntive che non sono presenti nella directory dell'app wwwroot , definire voci MSBuild ItemGroup aggiuntive, come illustrato nell'esempio seguente:

<ItemGroup>
  <ServiceWorkerAssetsManifestItem Include="MyDirectory\AnotherFile.json"
    RelativePath="MyDirectory\AnotherFile.json" AssetUrl="files/AnotherFile.json" />
</ItemGroup>

I AssetUrl metadati specificano l'URL relativo alla base che il browser deve usare durante il recupero della risorsa nella cache. Può essere indipendente dal nome del file di origine originale sul disco.

Importante

L'aggiunta di un ServiceWorkerAssetsManifestItem non causa la pubblicazione del file nella directory dell'app wwwroot. L'output di pubblicazione deve essere controllato separatamente. L'unico scopo ServiceWorkerAssetsManifestItem è far apparire una voce aggiuntiva nel manifest delle risorse del service worker.

Notifiche push

Come qualsiasi altro PWA, un Blazor WebAssembly pwa può ricevere notifiche push da un server back-end. Il server può inviare notifiche push in qualsiasi momento, anche quando l'utente non usa attivamente l'app. Ad esempio, le notifiche push possono essere inviate quando un utente diverso esegue un'azione pertinente.

Avvertenze per PWA offline

Non tutte le app devono tentare di supportare l'uso offline. Il supporto offline aggiunge una complessità significativa, pur non essendo sempre rilevante per i casi d'uso necessari.

Il supporto offline è in genere rilevante solo:

• Se l'archivio dati primario è locale nel browser. Ad esempio, l'approccio è rilevante in un'app con un'interfaccia utente per un dispositivo IoT che archivia i dati in localStorage o IndexedDB.
• Se l'app esegue una notevole quantità di lavoro per recuperare e memorizzare nella cache i dati dell'API back-end rilevanti per ogni utente in modo che possano spostarsi tra i dati offline. Se l'app deve supportare la modifica, è necessario compilare un sistema per tenere traccia delle modifiche e sincronizzare i dati con il back-end.
• Se l'obiettivo è garantire che l'app venga caricata immediatamente indipendentemente dalle condizioni di rete. Implementare un'esperienza utente appropriata per le richieste API back-end per mostrare lo stato di avanzamento delle richieste e comportarsi normalmente quando le richieste hanno esito negativo a causa dell'indisponibilità della rete.

Inoltre, le PWA con supporto offline devono gestire una serie di complicazioni aggiuntive. Gli sviluppatori devono acquisire attentamente familiarità con le avvertenze riportate nelle sezioni seguenti.

Supporto offline solo quando pubblicato

Durante lo sviluppo si vuole in genere visualizzare ogni modifica riflessa immediatamente nel browser senza passare attraverso un processo di aggiornamento in background. Di conseguenza, Blazoril modello PWA abilita il supporto offline solo quando viene pubblicato.

Quando si compila un'app con supporto offline, non è sufficiente testare l'app nell'ambiente Development . È necessario testare l'app nello stato pubblicato per comprendere in che modo risponde a diverse condizioni di rete.

Completamento dell'aggiornamento dopo lo spostamento dell'utente dall'app

Gli aggiornamenti non vengono completati finché l'utente non esce dall'app in tutte le schede. Come spiegato nella sezione Aggiornamenti in background, dopo aver distribuito un aggiornamento dell'app, il browser recupera i file aggiornati del service worker per avviare il processo di aggiornamento.

Ciò che sorprende molti sviluppatori è che, anche quando questo aggiornamento viene completato, non diventa effettivo fino a quando l'utente non si è spostato in tutte le schede. Non è sufficiente aggiornare la scheda che visualizza l'app, anche se è l'unica scheda che visualizza l'app. Fino a quando l'app non viene completamente chiusa, il nuovo service worker rimane nello stato di attesa di attivazione. Questo non è specifico di Blazor, ma piuttosto è un comportamento standard della piattaforma Web.

Questo problema si verifica comunemente per gli sviluppatori che cercano di testare gli aggiornamenti al loro service worker o alle risorse memorizzate nella cache offline. Se si selezionano gli strumenti di sviluppo del browser, è possibile che venga visualizzato un aspetto simile al seguente:

Finché l'elenco di "clienti", ovvero schede o finestre che visualizzano l'app, non è vuoto, il worker continua ad attendere. Il motivo per cui i lavoratori del servizio fanno questo è garantire la coerenza. Coerenza significa che tutte le risorse vengono recuperate dalla stessa cache atomica.

Quando si testano le modifiche, potrebbe risultare utile selezionare il collegamento "skipWaiting", come illustrato nello screenshot precedente, quindi ricaricare la pagina. È possibile automatizzare questa operazione per tutti gli utenti codificando il service worker per ignorare la fase di attesa e attivarsi immediatamente all'aggiornamento. Se si ignora la fase di attesa, si rinuncia alla garanzia che le risorse vengano sempre recuperate in modo coerente dalla stessa istanza della cache.

Gli utenti possono eseguire qualsiasi versione cronologica dell'app

Gli sviluppatori Web si aspettano abitualmente che gli utenti eseguano solo la versione distribuita più recente dell'app Web, perché è normale all'interno del modello di distribuzione Web tradizionale. Tuttavia, un PWA offline è più simile a un'app per dispositivi mobili nativa, in cui gli utenti non eseguono necessariamente la versione più recente.

Come spiegato nella sezione Aggiornamenti in background, dopo aver distribuito un aggiornamento all'app, ogni utente esistente continua a usare una versione precedente per almeno un'altra visita perché l'aggiornamento si verifica in background e non viene attivato fino a quando l'utente non si allontana. Inoltre, la versione precedente usata non è necessariamente quella precedente distribuita. La versione precedente può essere qualsiasi versione cronologica, a seconda dell'ultimo completamento di un aggiornamento da parte dell'utente.

Questo può essere un problema se le parti front-end e back-end dell'app richiedono un accordo sullo schema per le richieste API. Non è necessario distribuire le modifiche dello schema API non compatibili con le versioni precedenti fino a quando non è possibile assicurarsi che tutti gli utenti siano stati aggiornati. In alternativa, impedire agli utenti di usare versioni precedenti incompatibili dell'app. Questo requisito di scenario è identico a quello per le app per dispositivi mobili native. Se si distribuisce una modifica che causa un'interruzione nelle API del server, l'app client viene interrotta per gli utenti che non sono ancora stati aggiornati.

Se possibile, non distribuire modifiche di rilievo alle API back-end. In tal caso, è consigliabile usare API di lavoro di servizio standard, ad esempio ServiceWorkerRegistration , per determinare se l'app è aggiornata e, in caso contrario, per impedire l'utilizzo.

Interferenza con le pagine renderizzate dal server

Come descritto nella sezione Support server-rendered pages, se si vuole ignorare il comportamento del service worker di restituzione del /index.html contenuto per tutte le richieste di navigazione, modificare la logica nel service worker.

Tutti i contenuti del registro delle risorse dei service worker vengono memorizzati nella cache

Come descritto nella sezione Memorizzazione nella cache degli asset di controllo, il file service-worker-assets.js viene generato durante la compilazione ed elenca tutti gli asset che il service worker deve recuperare e memorizzare nella cache.

Poiché questo elenco include tutti gli elementi generati in wwwroot, incluso il contenuto fornito da pacchetti e progetti esterni, è necessario prestare attenzione a non inserire troppo contenuto. Se la wwwroot directory contiene milioni di immagini, il service worker tenta di recuperarle e memorizzarle tutte nella cache, consumando larghezza di banda in eccesso e probabilmente non completando con successo.

Implementare logica arbitraria per controllare quale subset del contenuto del manifesto deve essere recuperato e memorizzato nella cache modificando la onInstall funzione in service-worker.published.js.

Interazione con l'autenticazione

Il modello PWA può essere usato insieme all'autenticazione. Una pwa con supporto offline può supportare anche l'autenticazione quando l'utente dispone della connettività di rete iniziale.

Quando un utente non ha connettività di rete, non può autenticarsi o ottenere token di accesso. Il tentativo di visitare la pagina di accesso senza accesso alla rete genera un messaggio di errore di rete. È necessario progettare un flusso dell'interfaccia utente che consenta all'utente di eseguire attività utili offline senza tentare di autenticare l'utente o ottenere i token di accesso. In alternativa, è possibile progettare l'app in modo che gestisca il fallimento in modo appropriato quando la rete non è disponibile. Se l'app non può essere progettata per gestire questi scenari, potrebbe non essere necessario abilitare il supporto offline.

Quando un'app progettata per l'uso online e offline è di nuovo online:

• L'app potrebbe dover effettuare il provisioning di un nuovo token di accesso.
• L'app deve rilevare se un utente diverso ha eseguito l'accesso al servizio, così che essa possa applicare operazioni all'account dell'utente connesso che sono state eseguite mentre l'utente era offline.

Per creare un'app PWA offline che interagisce con l'autenticazione:

• Sostituire il AccountClaimsPrincipalFactory<TAccount> con una factory che memorizza l'ultimo utente connesso e utilizza l'utente memorizzato quando l'app è offline.
• Quando l'app è offline, accoda le operazioni e applicale quando l'app ritorna online.
• Durante la disconnessione, cancellare i dati dell'utente archiviati.

L'app CarChecker di esempio illustra gli approcci precedenti. Vedere le parti seguenti dell'app:

• OfflineAccountClaimsPrincipalFactory (Client/Data/OfflineAccountClaimsPrincipalFactory.cs)
• LocalVehiclesStore (Client/Data/LocalVehiclesStore.cs)
• LoginStatus componente (Client/Shared/LoginStatus.razor)

Risorse aggiuntive

• Risolvere i problemi relativi all'integrità dello script di PowerShell
• Negoziazione lato client tra SignalR origini per l'autenticazione