File System Access API の永続的な権限

権限を繰り返し付与することなく、ファイルやフォルダへの永続的な読み取り / 書き込みアクセス権を取得できるようになりました。この記事では、その仕組みについて説明します。詳細に入る前に、現状と解決すべき問題を簡単にまとめます。

現在の手法の課題

File System Access API を使用すると、デベロッパーはユーザーのローカル ハードディスク上のファイルに読み書き(オプション)でアクセスできます。この API を使用する人気のアプリの 1 つが、Visual Studio Code(VS Code)です。これは、ブラウザで直接動作する Microsoft の IDE です。VS Code を開くと、[ようこそ] 画面が表示されます。ここでは、新しいファイルを作成するか、既存のファイルまたはフォルダを開くことができます。

Visual Studio Code のウェルカム画面。

[フォルダを開く] をクリックしてハードディスク上のフォルダのいずれかを選択すると、VS Code にこのフォルダへの表示権限を付与するかどうかを尋ねるメッセージがブラウザに表示されます。

表示アクセス権を要求する Visual Studio Code。

アクセス権を付与すると、フォルダ階層を移動して、VS Code のエディタでファイルを開くことができます。ファイルに変更を加えると、フォルダへの編集権限を付与するかどうかをブラウザが確認します。

編集権限を求める Visual Studio Code。

アクセスを許可すると、アドレスバーのファイル アイコンが変わり、小さな下矢印が追加されます。これは、アプリに読み取りと書き込みの権限があることを示します。権限を変更するには、アイコン、[アクセス権を削除] の順にクリックして、アプリがファイルを編集できないようにします。

アドレスバーのアイコン プロンプトが表示された Visual Studio Code。

アクセスは、元のページの最後のタブを閉じるまで有効です。その後、アプリを閉じてもう一度開くと、VS Code は中断したところから再開できます。[最近使用したアイテム] をクリックすると、以前に開いたフォルダが再度開きます。

最後に開いたファイルを表示する Visual Studio Code。

ただし、以前にフォルダへの書き込み権限を付与していた場合でも、アクセス権を再度付与する必要があります。これはすぐに疲れてしまうものです。File System Access API の永続権限に関するソリューションの説明に入る前に、VS Code では最近使用したフォルダをどのように記憶しているのでしょうか。

再読み込み後に Visual Studio Code が編集権限をリクエストしています。

File System Access API では、ファイルとフォルダへのアクセスは FileSystemHandle オブジェクトによって管理されます。つまり、ファイルの場合は FileSystemFileHandle オブジェクト、フォルダ(ディレクトリ)の場合は FileSystemDirectoryHandle オブジェクトです。どちらも IndexedDB に保存できます。これが VS Code の役割です。これを確認するには、Chrome DevTools を開き、[Application] タブで [IndexedDB] セクションに移動し、vscode-web-db データベース内の関連するテーブル vscode-filehandles-store を選択します。

Visual Studio Code をデバッグする Chrome DevTools で、保存された FileSystemHandle を含む IndexedDB セクションが表示されている。

新しい方法: 変更点と時期

Chrome で、ファイルやフォルダへの永続的なアクセス権をユーザーが任意で付与できる新しい動作が導入されます。ユーザーに何度も再確認する必要がなくなります。新しい動作は Chrome 122 以降で確認できます。以前のテストを行うには、Chrome 120 以降で、chrome://flags/#file-system-access-persistent-permissionchrome://flags/#one-time-permission の 2 つのフラグを [有効] に切り替えます。

まず、新しい動作では、新しい 3 方向の権限プロンプトにより、ユーザーがアクセスのたびに選択したファイルやフォルダへのアクセス権をアプリに付与できます(オプション)。

Visual Studio Code と 3 方向権限プロンプト。

この新しい 3 方向プロンプトには、次のオプションがあります。

  • 今回は許可: 現在のセッションでのファイルへのアクセスを許可することをアプリに許可します。(これは既存の動作と同じです)。
  • アクセスのたびに許可: アクセス権が取り消されない限り、アプリに無期限のアクセスを許可します。アプリに永続アクセス権が付与されると、新しく開いたファイルとフォルダにも永続的にアクセスできます。
  • 許可しない: アプリにファイルへのアクセスを許可しません。(これは既存の動作に対応しています)。

次に、サイト設定に新しいセクションが追加され、[ファイルの編集] 切り替えボタンの横にある起動アイコンから操作できるようになります。

ファイル編集アイコン付きの Visual Studio Code サイト設定。

この起動アイコンをクリックすると、対象アプリの [プライバシーとセキュリティ] の設定が開き、アプリがアクセスできるすべてのファイルとフォルダのアイテムのリストが表示されます。ゴミ箱アイコンをクリックすると、アイテムごとにアクセス権を取り消すことができます。アイテムごとのアクセス権を削除しても、一般的なファイルへのアクセス権は引き続きアプリに付与できます。通常、アクセス権を取り消すには、前述のように、ユーザーはアドレスバーのアイコンをクリックします。

vscode.dev サイトの Chrome のプライバシーとセキュリティの設定。

新しい動作をトリガーする方法

File System Access API にデベロッパー向けの変更はありません。永続的な権限で新しい動作をトリガーするには、満たす必要があるさまざまな前提条件で次の 3 つの方法があります。

  1. ユーザーは、オリジンへの前回のアクセス時にファイルやフォルダ(または複数のファイルやフォルダ)に対する権限を付与しており、アプリが対応する FileSystemHandle オブジェクトを IndexedDB に保存している必要があります。オリジンへの次回アクセス時、アプリは、保存されている FileSystemHandle オブジェクトのいずれかを IndexedDB から取得し、FileSystemHandle.requestPermission() メソッドを呼び出しているはずです。これらの前提条件が満たされている場合、新しい 3 方向プロンプトが表示されます。
  2. オリジンは、以前にアクセス権が付与された FileSystemHandleFileSystemHandle.requestPermission() メソッドを呼び出しているが、タブがしばらくバックグラウンドであるため、アクセス権が自動的に取り消されている必要があります。(権限の自動取り消しは、Chrome の 1 回だけのアクセス許可で説明されているのと同じロジックに基づいて行われます)。これらの前提条件が満たされると、新しい 3 方向プロンプトが表示されます。
  3. ユーザーがアプリをインストール済みであることが必要です。インストール済みのアプリは、ユーザーがアクセス権を付与すると、自動的にその権限を保持します。この場合、三方向プロンプトは表示されず、アプリはデフォルトで新しい動作を取得します。

1 番目と 2 番目のケースでは、requestPermission() メソッドが呼び出されているオブジェクトだけでなく、アプリが以前にアクセスしていたすべての FileSystemHandle オブジェクトが一覧表示されます。1 回限りの権限での動作に合わせて、ユーザーがプロンプトを 3 回以上拒否または拒否するとトリガーされなくなり、代わりに通常の権限プロンプトが表示されます。

新しい動作を試す

サポート対象の Chrome バージョンを使用している場合や、必要なフラグが設定されている場合は、ウェブ上の VS Code で新しい動作をテストできます。フォルダを開いてアクセス権を付与し、タブを閉じて再度開いて [最近開く] をクリックします(即時再読み込みではプロンプトをトリガーできず、すべてのタブを閉じる必要があります)。前のフォルダを選択すると、新しいプロンプトが表示されます。テストケースをさらに減らすには、永続ファイル システム アクセスのデモを確認し、ソースコードを確認してください。

まとめ

File System Access API に対する永続的な権限は、API で最もリクエストの多い機能の 1 つであり、実装バグも非常に人気があり、多くのデベロッパーから高い評価を得ています。この機能をデベロッパー、そして何よりもユーザーが利用できるようにすることで、プラットフォーム固有のアプリと比べた重要な機能ギャップがなくなります。

謝辞

この投稿は、Christine HollingsworthAustin SullivanRachel Andrew がレビューしました。