Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

Gestione delle versioni

Magdalena Skarbińska

Demián Renzulli

Le app web isolate (IWA) offrono un ambiente di runtime sicuro, affidabile e con versioni discrete sulla piattaforma web. Negli ambienti di produzione, in particolare all'interno delle aziende gestite, gli amministratori e gli sviluppatori hanno bisogno di un controllo granulare sulle implementazioni software.

Per soddisfare questi requisiti, Chrome offre funzionalità complete di gestione delle versioni per le app web installabili, tra cui canali di aggiornamento, blocco delle versioni e downgrade delle versioni. Queste funzionalità consentono la prevedibilità dell'implementazione e controlli di ripristino rapido in tutta la base utenti.

Disponibilità

Il comportamento di gestione delle versioni dipende dal fatto che l'IWA sia gestita da un amministratore o installata direttamente da un utente:

IWA gestite:le funzionalità amministrative (inclusi l'aggiunta di pin basata su criteri e i downgrade) sono disponibili a partire da Chrome 133.
IWA non gestite (installate dall'utente):le funzionalità rivolte agli utenti (come la selezione manuale del canale) sono disponibili a partire da Chrome 150.

Compatibilità del tipo di sessione

Tutte le funzionalità di gestione delle versioni, inclusi i canali di aggiornamento e il blocco delle versioni, sono completamente compatibili con tutti i tipi di sessione ChromeOS. È incluso quanto segue:

Sessioni utente gestite standard
Sessioni Ospite gestite (MGS)
Ambienti modalità kiosk dedicati

Aggiornamento canali

Utilizzando i canali di aggiornamento, gli sviluppatori possono segmentare build di applicazioni specifiche per pubblici di test e deployment distinti. Per configurare i canali, aggiungi un campo facoltativo per l'array di canali a ogni voce di versione all'interno del manifest di aggiornamento dell'applicazione. Questi nomi dei canali non sono vincolati a parole chiave della piattaforma fisse (come canary o stable), ma sono identificatori arbitrari definiti dallo sviluppatore che devono essere formattati come stringhe alfanumeriche ASCII minuscole (che possono includere trattini o caratteri di sottolineatura, ma non spazi). Se una voce di versione omette completamente il campo dei canali, Chrome imposta implicitamente la sua disponibilità sul canale "default". In definitiva, il nome del canale designato nel criterio amministrativo deve corrispondere esattamente alla stringa definita nel manifest; eventuali errori tipografici o configurazioni non corrispondenti comporteranno l'impossibilità di identificare una versione idonea, interrompendo di fatto gli aggiornamenti per questi client.

Configurazione del manifest

Per configurare i canali, aggiungi un array channels facoltativo a ogni voce di versione nel manifest dell'app web. Ecco alcuni aspetti da prendere in considerazione:

Mappatura dei canali:se una voce di versione definisce un array channels, questa versione è idonea per l'installazione solo sui canali specificati.
Fallback predefinito:se una voce di versione omette completamente il campo channels, Chrome presuppone che la versione appartenga esclusivamente al canale default.
Corrispondenza esatta delle stringhe:i nomi dei canali specificati nelle configurazioni delle policy lato client devono corrispondere esattamente alle stringhe definite nel file manifest di aggiornamento (rispettando la distinzione tra maiuscole e minuscole). Se nessuna versione corrisponde al nome del canale di destinazione, l'app non riuscirà a trovare gli aggiornamenti idonei.

Aggiornamento esempio di manifest

L'esempio seguente mostra un manifest di aggiornamento che supporta più canali di rilascio:

{
  "versions": [
    {
      "version": "0.1.0",
      "src": "https://github.com/chromeos/iwa-sink/releases/download/v0.1.0/iwa-sink.swbn",
      "channels": ["delta"]
    },
    {
      "version": "0.2.0",
      "src": "https://github.com/chromeos/iwa-sink/releases/download/v0.2.0/iwa-sink.swbn",
      "channels": ["delta", "default"]
    },
    {
      "version": "0.3.0",
      "src": "https://github.com/chromeos/iwa-sink/releases/download/v0.3.0/iwa-sink.swbn",
      "channels": ["beta", "delta"]
    },
    {
      "version": "0.4.0",
      "src": "https://github.com/chromeos/iwa-sink/releases/download/v0.4.0/iwa-sink.swbn"
    }
  ]
}

In base a questo manifest, sono disponibili le seguenti versioni per canale di destinazione:

default: 0.2.0,0.4.0 (che non ha un canale esplicito e utilizza il valore predefinito)
delta: 0.1.0, 0.2.0, 0.3.0
beta: 0.3.0

Il motore di aggiornamento delle IWA supporta il targeting di canali di rilascio specifici cercando un campo canali all'interno del manifest di aggiornamento dell'app.

Blocco delle versioni

In ambienti aziendali con elevati requisiti di conformità o altamente stabili, gli amministratori devono assicurarsi che i dispositivi eseguano versioni esatte di software essenziali per l'attività. Il blocco delle versioni consente agli amministratori di bloccare un'IWA a una versione specifica, interrompendo tutti gli aggiornamenti in background successivi. In questo modo, le aziende dispongono di un modo altamente affidabile per mantenere configurazioni stabili e rispettare normative interne o di settore rigorose.

Per bloccare un'app web isolata (IWA) su una build di rilascio specifica, gli amministratori aziendali possono configurare la proprietà pinned_version all'interno della policy IsolatedWebAppInstallForceList. Questa funzionalità viene gestita principalmente tramite i controlli dell'interfaccia utente interattiva nella Console di amministrazione Google nel riquadro dei dettagli dell'applicazione seguendo il flusso di lavoro di installazione IWA standard, anche se gli amministratori mantengono la flessibilità di implementare questi valori dei criteri direttamente utilizzando le configurazioni JSON non elaborate. Una volta che una stringa di versione valida è stata selezionata correttamente dall'amministratore, Chrome recupera il pacchetto esplicito e blocca tutti gli aggiornamenti automatici successivi.

Comportamenti e vincoli speciali

Ripresa degli aggiornamenti (rimozione del blocco): per ripristinare gli aggiornamenti automatici, rimuovi la proprietà pinned_version o modificale il valore in una versione di destinazione più recente.
Nessun downgrade per impostazione predefinita: l'impostazione di pinned_version su una versione precedente a quella attualmente installata non attiverà un rollback, a meno che allow_downgrades non sia abilitato esplicitamente.
Destinazioni di blocco non disponibili:se il pinned_version configurato non è presente nel canale di aggiornamento designato o è precedente alla versione installata (con i downgrade disattivati), Chrome manterrà la versione attualmente installata e bloccherà ulteriori aggiornamenti.
Nuove implementazioni: se un'IWA non è ancora installata su un dispositivo gestito e la pinned_version specificata non può essere recuperata o non è presente nel manifest di aggiornamento, l'installazione dell'IWA non andrà a buon fine.

Downgrade della versione

Se un aggiornamento appena implementato introduce un bug o una vulnerabilità critica, gli amministratori potrebbero dover eseguire il rollback dei dispositivi a uno stato stabile precedente. Chrome supporta il downgrade delle IWA gestite già installate a una versione precedente, una funzionalità precedentemente non disponibile sulla piattaforma quando erano consentiti solo gli aggiornamenti in avanti.

Il downgrade è possibile solo se sono soddisfatte entrambe le seguenti condizioni delle norme:

pinned_version è impostato su una versione precedente valida.
allow_downgrades è impostato esplicitamente su true.

Come funzionano i downgrade

Meccanismo di attivazione:i rollback vengono elaborati durante il normale ciclo di controllo degli aggiornamenti (che viene eseguito ogni 4-6 ore).
Funzionamento interno: Chrome esegue una reinstallazione completa dell'IWA utilizzando il bundle web precedente (.swbn) specificato nel manifest di aggiornamento.

Logica di transizione del canale

Quando si cambia il canale di destinazione di un'app con un criterio, il motore di aggiornamento rispetta comportamenti specifici:

Scenario A: passaggio a un canale con versioni precedenti

Se il downgrade è consentito:se pinned_version corrisponde a una versione precedente sul canale di destinazione e allow_downgrades è true, viene eseguito un rollback (e i dati utente locali vengono cancellati).
Se il downgrade non è consentito:non verrà eseguito alcun downgrade. Il dispositivo rimarrà sulla versione superiore attualmente installata e verrà aggiornato solo quando una versione più recente diventerà disponibile sul canale appena selezionato.

Scenario B: passaggio a un canale con una versione identica

Nessuna modifica: se il canale appena selezionato punta a un numero di versione uguale a quello attualmente installato, Chrome non apporterà alcuna modifica al bundle installato.
Principio di identità byte per byte:gli sviluppatori devono garantire che i numeri di versione identici su canali diversi contengano firme di codice identiche che corrispondono byte per byte. Il deployment di codebase diverse con la stessa stringa di versione su più canali può comportare stati dell'applicazione imprevisti ed errati.

Configurazione dei criteri amministrativi

I controlli delle versioni aziendali vengono applicati con la piattaforma centralizzata della Console di amministrazione Google utilizzando lo schema della policy IsolatedWebAppInstallForceList. Queste impostazioni possono essere gestite direttamente tramite i controlli dell'interfaccia utente nella Console di amministrazione o implementate utilizzando configurazioni dei criteri JSON non elaborati.
Il seguente esempio di configurazione delle norme amministrative mostra i canali di aggiornamento, il blocco delle versioni e i downgrade:

Rappresentazione del valore della policy

[
  {
    "update_manifest_url": "https://awesome-kitchen-sink.glitch.me/update.json",
    "web_bundle_id": "aiv4bxauvcu3zvbu6r5yynoh4atkzqqaoeof5mwz54b4zfywcrjuoaacai",
    "channel": "beta",
    "pinned_version": "0.7.0",
    "allow_downgrades": true
  }
]

Spiegazioni dei parametri dello schema

channel (stringa, facoltativa): indica a Chrome di valutare solo le versioni assegnate a questo canale nel manifest di aggiornamento. Se omesso, Chrome valuta il canale "default".
pinned_version (stringa, facoltativa): blocca esplicitamente il dispositivo alla stringa di versione specificata. I successivi aggiornamenti automatici in background vengono bloccati.
allow_downgrades (booleano, facoltativo): attiva la funzionalità di rollback. Se è impostato su true e abbinato a un pinned_version precedente valido, Chrome attiverà una reinstallazione del downgrade. Avviso:se imposti questo parametro su true, vengono bloccati tutti gli aggiornamenti standard anche se il campo pinned_version viene omesso.

IWA non gestite (installate dall'utente) (da 150)

Per le app web isolate non gestite e installate dall'utente, il controllo delle versioni funziona con interazioni manuali dell'utente:

Pacchetto di installazione ──► L'utente seleziona il canale ──► Controlli automatici sul canale selezionato

Prerequisito del manifest per gli aggiornamenti automatici

Affinché le IWA installate dagli utenti controllino e ricevano aggiornamenti periodici automatici in background, il manifest dell'app web locale dell'app (i metadati inclusi nel bundle in /.well-known/manifest.webmanifest) deve contenere un campo update_manifest_url valido.

Se questo URL viene omesso dal file manifest locale dell'applicazione, il motore di aggiornamento non gestito non eseguirà mai controlli in background e l'applicazione rimarrà bloccata in modo permanente sulla versione di installazione iniziale.

Selezione manuale dei canali

Durante l'installazione iniziale di un'IWA non gestita, il browser controlla il manifesto di aggiornamento e mostra direttamente all'utente le opzioni di canale disponibili (ad esempio "Stabile", "Beta") se lo sviluppatore ha configurato più canali.

Regole del ciclo di vita delle chiavi

Origine della prima installazione:indipendentemente dal canale selezionato dall'utente durante l'installazione, l'installazione iniziale distribuisce sempre i file inclusi nel bundle di installazione fornito.
Aggiornamenti successivi:una volta installati, gli aggiornamenti futuri vengono eseguiti esclusivamente dal canale scelto. L'app verrà aggiornata solo quando una versione superiore a quella installata viene pubblicata sul canale di destinazione.
Cambio di canale: per passare a un altro canale di aggiornamento dopo l'installazione, l'utente deve disinstallare l'IWA e reinstallarlo, scegliendo il canale selezionato durante il flusso di installazione.

Come testare i deployment gestiti

Per gli amministratori che gestiscono i dispositivi tramite la Console di amministrazione Chrome Enterprise o che configurano direttamente i criteri:

Vai al riquadro Dettagli app nelle impostazioni dell'organizzazione.
Applica le proprietà di configurazione per testare il blocco e i canali di destinazione. Poiché questi controlli sono completamente compatibili con le sessioni utente standard, le sessioni guest gestite (MGS) e i chioschi, puoi verificare i comportamenti in tutti gli ambienti di deployment di destinazione.
Per esaminare localmente i controlli degli aggiornamenti, vai a chrome://web-app-internals su un client di test per forzare manualmente i controlli degli aggiornamenti e analizzare i pacchetti manifest in entrata.

Conclusione

L'architettura di sicurezza delle app web isolate è progettata per consentire agli sviluppatori di mantenere una prevedibilità e un controllo rigorosi sul comportamento del ciclo di vita delle applicazioni. Sfruttando le funzionalità di gestione delle versioni di Chrome, sia gli sviluppatori che gli amministratori IT possono creare pipeline di deployment robuste che rispettano standard di conformità rigorosi e obiettivi operativi.

Quando progetti e gestisci la strategia di aggiornamento della tua applicazione, tieni presente questi principi fondamentali:

Utilizza i canali progressivi:i canali di aggiornamento (come beta, dev o gli anelli personalizzati) ti consentono di raccogliere progressivamente dati di telemetria e feedback. Ciò garantisce che gli aggiornamenti principali vengano sottoposti a una verifica rigorosa prima di essere distribuiti alla popolazione generale sul canale predefinito.
Blocco per la stabilità: in ambienti aziendali altamente strutturati o basati sulla conformità, blocca gli endpoint critici su una pinned_version esatta e verificata per proteggere le operazioni da interruzioni impreviste o interruzioni del flusso di lavoro.
Riserva i downgrade per le emergenze: riconosci che il downgrade della versione è una valvola di sicurezza correttiva potente, precedentemente impossibile. Tuttavia, poiché un rollback attiva una reinstallazione completa ed elimina tutto lo spazio di archiviazione locale del client (IndexedDB, LocalStorage, cookie), deve essere riservato rigorosamente alla correzione di problemi di sicurezza critici. Per le patch ordinarie, l'ideale è sempre implementare un aggiornamento secondario lungimirante.
Comprendi i flag delle norme:presta attenzione agli switch amministrativi; l'attivazione di allow_downgrades interromperà tutti gli aggiornamenti futuri anche se un pin non è definito attivamente.
Stabilisci l'integrità byte per byte:assicurati che i numeri di versione identici implementati su canali diversi corrispondano a bundle identici e corrispondenti byte per byte per evitare stati dell'applicazione irregolari quando i client passano da un canale all'altro.

Integrando queste funzionalità direttamente nello schema del file manifest degli aggiornamenti e delle norme aziendali, puoi garantire un flusso di aggiornamento affidabile, verificabile e sicuro che preservi le garanzie di elevata affidabilità dell'ecosistema delle app web isolate.