Il existe désormais un moyen d'obtenir un accès persistant en lecture et en écriture aux fichiers et aux dossiers sans avoir à accorder des autorisations à plusieurs reprises. Cet article explique comment cela fonctionne. Avant d'entrer dans les détails, un bref récapitulatif du statu quo et du problème à résoudre.
Défis de la méthode actuelle
L'API File System Access permet aux développeurs d'accéder en lecture et (éventuellement) aux fichiers stockés sur le disque dur local de l'utilisateur. Visual Studio Code (VS Code), l'IDE de Microsoft qui s'exécute directement dans le navigateur, est une application populaire (parmi de nombreuses autres) qui utilise cette API. Lorsque vous ouvrez VS Code, un écran Welcome (Bienvenue) s'affiche. Vous pouvez y créer un fichier, ou ouvrir un fichier existant ou un dossier.
Si vous cliquez sur Open Folder (Ouvrir le dossier) et que vous choisissez l'un des dossiers sur votre disque dur, le navigateur vous demandera si vous souhaitez que VS Code dispose d'un accès en lecture à ce dossier.
Une fois que vous avez accordé l'accès, vous pouvez naviguer dans la hiérarchie des dossiers et ouvrir des fichiers dans l'éditeur de VS Code. Si vous apportez une modification à l'un des fichiers, le navigateur vous demande si vous souhaitez accorder un accès en écriture au dossier.
Si vous l'autorisez, l'icône de fichier dans la barre d'adresse change, et une petite flèche vers le bas est ajoutée pour indiquer que l'application dispose d'autorisations de lecture et d'écriture. Pour modifier les autorisations, cliquez sur l'icône, puis sur Supprimer l'accès afin que l'application ne puisse plus modifier de fichiers.
L'accès reste actif jusqu'à ce que vous fermiez le dernier onglet de l'origine. Si vous fermez l'application, puis que vous la rouvrez, VS Code vous permet de reprendre là où vous en étiez. Lorsque vous cliquez sur Open Recent (Ouvrir récent), VS Code propose de rouvrir le dossier précédemment ouvert.
Toutefois, même si vous avez déjà accordé une autorisation en écriture au dossier, vous devez maintenant accorder à nouveau l'accès. Cela devient très rapidement fatigué. Avant d'examiner la solution, à savoir les autorisations persistantes pour l'API File System Access, comment VS Code parvient-il même à mémoriser les dossiers récents ?
Dans l'API File System Access, l'accès aux fichiers et aux dossiers est géré via des objets FileSystemHandle
: objets FileSystemFileHandle
pour les fichiers et objets FileSystemDirectoryHandle
pour les dossiers (répertoires). Les deux peuvent être stockés dans IndexedDB, et c'est exactement ce que fait VS Code. Pour ce faire, ouvrez les outils pour les développeurs Chrome, accédez à la section IndexedDB dans l'onglet Application, puis sélectionnez la table appropriée vscode-filehandles-store
dans la base de données vscode-web-db
.
Nouvelle méthode: qu'est-ce qui change et quand ?
Chrome lance un nouveau comportement permettant aux utilisateurs d'accorder un accès permanent à leurs fichiers et dossiers, ce qui leur évite d'avoir à les inviter constamment.
Ce nouveau comportement est observé à partir de Chrome 122. Pour le tester plus tôt, à partir de Chrome 120, définissez les deux indicateurs chrome://flags/#file-system-access-persistent-permission
et chrome://flags/#one-time-permission
sur Enabled (Activé).
Tout d'abord, le nouveau comportement consiste en une nouvelle invite d'autorisation à trois voies qui permet éventuellement aux applications d'accorder aux applications l'accès aux fichiers et dossiers sélectionnés à chaque visite.
Cette nouvelle invite à trois voies propose les options suivantes:
- Autoriser cette fois:permet à l'application d'accéder aux fichiers de la session en cours. (Cela correspond au comportement existant.)
- Autoriser à chaque visite:autorise l'application à disposer d'un accès illimité, sauf s'il est révoqué. Une fois que l'application dispose d'un accès persistant, les fichiers et dossiers nouvellement ouverts sont également accessibles de manière persistante.
- Ne pas autoriser:empêche l'application d'accéder aux fichiers. (Cela correspond au comportement existant.)
Deuxièmement, le nouveau comportement implique une nouvelle section dans les paramètres du site, à laquelle les utilisateurs peuvent accéder via une icône de lancement à côté du bouton Modification de fichier.
Lorsqu'elle clique sur cette icône de lancement, elle ouvre les paramètres Confidentialité et sécurité de l'application en question. L'utilisateur voit alors une liste d'éléments pour tous les fichiers et dossiers auxquels l'application a accès. L'accès peut être révoqué pour chaque élément en cliquant sur l'icône de la corbeille. Supprimer l'accès par élément signifie que l'application peut toujours avoir accès aux fichiers en général. Pour révoquer l'accès en général, l'utilisateur peut cliquer sur l'icône dans la barre d'adresse, comme décrit précédemment.
Déclencher le nouveau comportement
Aucune modification n'a été apportée aux développeurs concernant l'API File System Access. Pour déclencher le nouveau comportement avec des autorisations persistantes, trois méthodes avec différentes conditions préalables doivent être remplies:
- L'utilisateur doit avoir accordé des autorisations à un fichier ou à un dossier (ou à plusieurs fichiers ou dossiers) lors de la dernière visite d'une origine. L'application doit avoir stocké les objets
FileSystemHandle
correspondants dans IndexedDB. Lors de la prochaine visite sur l'origine, l'application doit avoir récupéré l'un des objetsFileSystemHandle
stockés à partir d'IndexedDB, puis appelé sa méthodeFileSystemHandle.requestPermission()
. Si ces conditions préalables sont remplies, la nouvelle invite à trois sens s'affiche. - L'origine doit avoir appelé la méthode
FileSystemHandle.requestPermission()
sur unFileSystemHandle
auquel l'accès avait été accordé auparavant, mais dont l'accès a été automatiquement révoqué en raison du passage en arrière-plan de l'onglet pendant un certain temps. (La révocation automatique des autorisations fonctionne selon la même logique que celle décrite dans l'article Autorisations ponctuelles dans Chrome.) Si ces conditions préalables sont remplies, la nouvelle invite à trois voies s'affiche. - L'utilisateur doit avoir installé l'application. Les applications installées conservent automatiquement les autorisations une fois que l'utilisateur accorde l'accès. Dans ce cas, l'invite à trois sens ne s'affiche pas. L'application obtient le nouveau comportement par défaut.
Dans le premier et le second cas, l'invite répertorie tous les objets FileSystemHandle
auxquels l'application avait précédemment accès, et pas seulement celui pour lequel la méthode requestPermission()
est appelée. Conformément à la façon dont cela fonctionne dans les autorisations ponctuelles, si l'utilisateur refuse ou ignore l'invite plus de trois fois, celle-ci ne se déclenchera plus. L'invite d'autorisation standard s'affichera à la place.
Essayer le nouveau comportement
Si vous disposez d'une version compatible de Chrome ou si les indicateurs requis sont définis, vous pouvez tester le nouveau comportement dans VS Code sur le Web. Ouvrez un dossier et accordez l'accès, puis fermez l'onglet, puis rouvrez-le et cliquez sur Ouvrir le dossier récent (notez que l'actualisation immédiate ne fonctionne pas pour déclencher l'invite, car vous devez fermer tous les onglets). Sélectionnez le dossier précédent pour afficher la nouvelle invite. Pour un scénario de test plus réduit, regardez la démonstration de l'accès au système de fichiers persistant et consultez son code source.
Conclusions
Les autorisations persistantes pour l'API File System Access sont l'une des fonctionnalités les plus demandées de l'API, et le bug d'implémentation est également très populaire, et de nombreux développeurs l'ajoutent aux favoris. En mettant cette fonctionnalité entre les mains des développeurs et, surtout, des utilisateurs, nous avons comblé une lacune importante en termes de fonctionnalités par rapport aux applications spécifiques à la plate-forme.
Remerciements
Ce post a été examiné par Christine Hollingsworth, Austin Sullivan et Rachel Andrew.