Autorizzazioni permanenti per l'API File System Access

Ora è possibile ottenere l'accesso in lettura e scrittura persistente a file e cartelle senza dover concedere ripetutamente le autorizzazioni. Questo post spiega come funziona. Prima di entrare nei dettagli, un breve riepilogo dello stato attuale e del problema che viene risolto.

Sfide relative al metodo attuale

L'API File System Access consente agli sviluppatori di accedere ai file sul disco rigido locale dell'utente in modalità di lettura e (facoltativamente) scrittura. Una delle app più diffuse (tra molte altre) che utilizza questa API è Visual Studio Code (VS Code), l'IDE di Microsoft che viene eseguito direttamente nel browser. Quando apri VS Code, viene visualizzata una schermata di benvenuto in cui puoi creare un nuovo file o aprire un file o una cartella esistenti.

Schermata di benvenuto di Visual Studio Code.

Se fai clic su Apri cartella e scegli una delle cartelle sul disco rigido, il browser ti chiederà se vuoi che VS Code abbia accesso di visualizzazione a questa cartella.

Visual Studio Code che chiede l'accesso in visualizzazione.

Una volta concesso l'accesso, puoi navigare nella gerarchia delle cartelle e aprire i file nell'editor di VS Code. Se apporti una modifica a uno dei file, il browser ti chiederà se vuoi concedere l'accesso in modifica alla cartella.

Visual Studio Code chiede l'accesso in modifica.

Se lo consenti, l'icona del file nella barra degli indirizzi cambia e viene aggiunta una piccola freccia giù, che indica che l'app dispone delle autorizzazioni di lettura e scrittura. Per modificare le autorizzazioni, fai clic sull'icona e poi su Rimuovi accesso, in modo che l'app non possa più modificare i file.

Visual Studio Code con prompt dell'icona della barra degli indirizzi.

L'accesso dura fino alla chiusura dell'ultima scheda dell'origine. Se poi chiudi l'app e la riapri, VS Code ti consente in qualche modo di continuare da dove avevi interrotto. Quando fai clic su Apri recente, VS Code offre la cartella aperta in precedenza per la riapertura.

Visual Studio Code che offre gli ultimi file aperti.

Tuttavia, anche se in precedenza hai concesso l'autorizzazione di scrittura alla cartella, ora devi concedere nuovamente l'accesso. Questa situazione diventa stancante molto rapidamente. Prima di passare alla soluzione, ovvero le autorizzazioni persistenti per l'API File System Access, come fa VS Code a ricordare le cartelle recenti?

Visual Studio Code chiede l'accesso in modifica dopo il ricaricamento.

Nell'API File System Access, l'accesso a file e cartelle viene gestito tramite oggetti FileSystemHandle: FileSystemFileHandle per i file e FileSystemDirectoryHandle per le cartelle (directory). Entrambi possono essere memorizzati in IndexedDB, ed è esattamente quello che fa VS Code. Puoi verificarlo aprendo Chrome DevTools, nella scheda Applicazione vai alla sezione IndexedDB e seleziona la tabella pertinente vscode-filehandles-store nel database vscode-web-db.

Debug di Chrome DevTools in Visual Studio Code che mostra la sezione IndexedDB con FileSystemHandle memorizzato.

Il nuovo modo: cosa cambia e quando

Chrome sta introducendo un nuovo comportamento per consentire agli utenti di concedere facoltativamente l'accesso permanente ai propri file e alle proprie cartelle, evitando la necessità di richiedere costantemente l'autorizzazione all'utente. Il nuovo comportamento può essere osservato a partire da Chrome 122. Per testarlo in anticipo, a partire da Chrome 120, attiva i due flag chrome://flags/#file-system-access-persistent-permission e chrome://flags/#one-time-permission su Attivato.

Innanzitutto, il nuovo comportamento consiste in una nuova richiesta di autorizzazione a tre vie che consente facoltativamente agli utenti di concedere alle app l'accesso a file e cartelle selezionati a ogni visita.

Visual Studio Code con prompt di autorizzazione a tre vie.

Questo nuovo prompt a tre vie offre le seguenti opzioni:

  • Consenti per questo periodo di tempo:consente all'app di accedere ai file per la sessione corrente. (Ciò corrisponde al comportamento esistente.)
  • Consenti a ogni visita:consente all'app di avere accesso illimitato, a meno che l'accesso non venga revocato. Una volta concesso l'accesso persistente all'app, anche i file e le cartelle aperti di recente saranno accessibili in modo persistente.
  • Non consentire:non consente all'app di accedere ai file. (Questo corrisponde al comportamento esistente.)

In secondo luogo, il nuovo comportamento comporta una nuova sezione nelle impostazioni del sito, a cui gli utenti possono accedere tramite un'icona di avvio accanto all'opzione di attivazione/disattivazione Modifica file.

Impostazioni del sito di Visual Studio Code con l'icona di modifica del file.

Se fai clic su questa icona di avvio, si aprono le impostazioni di Privacy e sicurezza per l'app in questione, dove l'utente vede un elenco di elementi per tutti i file e le cartelle a cui l'app ha accesso. L'accesso può essere revocato per ogni singolo elemento facendo clic sull'icona del cestino. La rimozione dell'accesso per elemento significa che l'app può comunque ottenere l'accesso ai file in generale. Per revocare l'accesso in generale, l'utente può fare clic sull'icona nella barra degli indirizzi, come descritto in precedenza.

Impostazioni di privacy e sicurezza di Chrome per il sito vscode.dev.

Come attivare il nuovo comportamento

Non sono state apportate modifiche all'API File System Access per gli sviluppatori. Per attivare il nuovo comportamento con le autorizzazioni persistenti, esistono tre modi con diverse precondizioni da soddisfare:

  1. L'utente deve aver concesso l'autorizzazione a un file o a una cartella (o a più file o cartelle) durante l'ultima visita a un'origine e l'app deve aver memorizzato gli oggetti FileSystemHandle corrispondenti in IndexedDB. Alla visita successiva all'origine, l'app deve aver recuperato uno qualsiasi degli oggetti FileSystemHandle archiviati da IndexedDB e poi aver chiamato il metodo FileSystemHandle.requestPermission(). Se queste condizioni preliminari sono soddisfatte, verrà visualizzato il nuovo prompt a tre vie.
  2. L'origine deve aver chiamato il metodo FileSystemHandle.requestPermission() su un FileSystemHandle a cui è stato concesso l'accesso in precedenza, ma il cui accesso è stato revocato automaticamente perché la scheda è rimasta in background per un po' di tempo. (La revoca automatica delle autorizzazioni funziona in base alla stessa logica descritta nell'articolo Autorizzazioni temporanee in Chrome.) Se queste condizioni preliminari sono soddisfatte, verrà visualizzato il nuovo prompt a tre vie.
  3. L'utente deve aver installato l'app. Una volta concesso l'accesso, le autorizzazioni delle app installate verranno mantenute automaticamente. In questo caso, non verrà mostrato il prompt a tre vie, ma l'app avrà il nuovo comportamento per impostazione predefinita.

Nel primo e nel secondo caso, il prompt elenca tutti gli oggetti FileSystemHandle a cui l'app aveva accesso in precedenza, non solo quello per cui viene chiamato il metodo requestPermission(). In linea con il funzionamento delle autorizzazioni temporanee, se l'utente nega o chiude il prompt più di tre volte, questo non verrà più visualizzato e verrà mostrato il normale prompt di autorizzazione.

Prova il nuovo comportamento

Se hai una versione supportata di Chrome o hai impostato i flag richiesti, puoi testare il nuovo comportamento in VS Code sul web. Apri una cartella e concedi l'accesso, poi chiudi la scheda, riaprila e fai clic su Apri recente (tieni presente che il ricaricamento immediato non funziona per attivare la richiesta, tutte le schede devono essere chiuse). Scegli la cartella precedente e verrà visualizzato il nuovo prompt.

Conclusioni

Le autorizzazioni persistenti per l'API File System Access sono una delle funzionalità più richieste dell'API e anche il bug di implementazione è molto popolare, con molti sviluppatori che lo hanno aggiunto ai preferiti. Portando questa funzionalità nelle mani degli sviluppatori e, soprattutto, degli utenti, è stata colmata un'importante lacuna rispetto alle app specifiche per piattaforma.

Riconoscimenti

Questo post è stato esaminato da Christine Hollingsworth, Austin Sullivan e Rachel Andrew.