From 33058f2b292b3a581333bdfb21b8f671898c5060 Mon Sep 17 00:00:00 2001 From: Peter Bengtsson Date: Tue, 8 Dec 2020 14:40:17 -0500 Subject: initial commit --- files/ja/web/api/storage_access_api/index.html | 93 ++++++++++++++++++++++ .../ja/web/api/storage_access_api/using/index.html | 53 ++++++++++++ 2 files changed, 146 insertions(+) create mode 100644 files/ja/web/api/storage_access_api/index.html create mode 100644 files/ja/web/api/storage_access_api/using/index.html (limited to 'files/ja/web/api/storage_access_api') diff --git a/files/ja/web/api/storage_access_api/index.html b/files/ja/web/api/storage_access_api/index.html new file mode 100644 index 0000000000..853faa4325 --- /dev/null +++ b/files/ja/web/api/storage_access_api/index.html @@ -0,0 +1,93 @@ +--- +title: Storage Access API +slug: Web/API/Storage_Access_API +tags: + - API + - Reference + - Storage + - Storage Access API +translation_of: Web/API/Storage_Access_API +--- +
{{DefaultAPISidebar("Storage Access API")}}{{seecompattable}}
+ +

Storage Access API（ストレージアクセス API）は、埋め込まれたクロスオリジンのコンテンツが、通常はファーストパーティのコンテキストでのみアクセスできるストレージ（これをオリジンのファーストパーティストレージと呼びます）に無制限にアクセスする方法を提供します。 API は、埋め込まれたリソースがファーストパーティストレージに現在アクセスできるかどうかを確認し、ユーザーエージェントからファーストパーティストレージへのアクセスを要求できるメソッドを提供します。

+ +

概念と使用方法

+ +

ほとんどのブラウザーは、埋め込まれたクロスオリジンリソースのクッキーおよびサイトデータへのアクセスを制限する多くのストレージアクセスポリシーを実装しています。 これらの制限は、各最上位オリジンの下に埋め込まれたリソースに一意のストレージスペースを与えることから、サードパーティのコンテキストでリソースが読み込まれたときのストレージアクセスの完全なブロックにまで及びます。

+ +

特にサードパーティのクッキーブロックポリシーに関する意味論はブラウザーごとに異なりますが、コア機能は似ています: サードパーティのコンテキストに埋め込まれたクロスオリジンリソースには、ファーストパーティのコンテキストで読み込まれたときにアクセスできるのと同じクッキーとサイトストレージへのアクセスが与えられません。

+ +

これらのクッキーブロックポリシーは、ファーストパーティストレージへのアクセスを必要とする埋め込まれたクロスオリジンコンテンツを中断することが知られています。 例として、フェデレーションログイン（federated login、複数組織にまたがったログイン）では、ファーストパーティストレージに保存されている認証クッキーへのアクセスが必要になることが多く、これらのクッキーが利用できない場合、ユーザーは各サイトに個別にサインインする（または完全に中断する）必要があります。 中断した場合、サイト所有者は、ユーザーにサイトを例外として追加するか、ポリシーを完全に無効にすることを推奨することがよくあります。 結果として、埋め込まれたコンテンツとのやり取りを継続することを希望するユーザーは、すべての埋め込まれたオリジンおよびおそらくすべてのウェブサイトから読み込まれたリソースのブロックポリシーを大幅に緩和する必要があります。

+ +

Storage Access API は、この問題を解決することを目的としています。 埋め込まれたクロスオリジンのコンテンツは、{{domxref("Document.requestStorageAccess()")}} メソッドを介してサイトごとにファーストパーティストレージへの無制限のアクセスを要求し、{{domxref("Document.hasStorageAccess()")}} メソッドを介して既にアクセス権があるかどうかを確認できます。

+ +

さらに、セキュリティ上の理由から、サンドボックス化した {{htmlelement("iframe")}} にはデフォルトでストレージアクセスを許可できません。 そのため、API は、allow-storage-access-by-user-activation sandbox トークンも追加します。 次のように、埋め込まれたウェブサイトは、これを追加してストレージアクセス要求が成功することを許可するとともに、allow-scripts と allow-same-origin を使用して API の呼び出しを許可し、クッキーを持つことができるオリジンで実行します。

+ +
<iframe sandbox="allow-storage-access-by-user-activation
+                 allow-scripts
+                 allow-same-origin">
+  ...
+</iframe>
+ +

API は、潜在的なストレージの例外を、ユーザーがやり取りする意図を示したオリジンに制限するように設計されています。 これは、次の制約によって実施されます。

+ + + +

ブラウザーは、到来するストレージアクセス要求を許可するかどうかの決定にユーザーを関与させることを決定する場合があります。 ストレージ許可の存続期間とブラウザーがユーザーに通知することを決定する状況に関する詳細は現在作業中であり、準備ができ次第発表されます。

+ +

ユーザープロンプト

+ +

埋め込まれたクロスオリジンの文書によって requestStorageAccess() が呼び出されると、ユーザーエージェントは、要求オリジンにストレージアクセスを許可するかどうかの決定にユーザーを関与させることを選択できます。 現在、プロンプトヒューリスティック（Prompting heuristics、プロンプトするべきかを決める発見的方法）は Storage Access API の2つの実装者によって異なります。 Safari は、以前にストレージアクセスを受け取っていないすべての埋め込まれた追跡コンテンツにプロンプトを表示します。 Firefox は、追跡オリジンがサイトのしきい値数を超えてストレージアクセスを要求した後にのみユーザーにプロンプトします。 詳細については、{{domxref("Document.requestStorageAccess()")}} を参照してください。

+ +

Safari の実装との違い

+ +

API の表面は同じですが、Storage Access API を使用するウェブサイトは、Firefox と Safari の間で受け取るストレージアクセスのレベルと範囲に違いがあることを予期する必要があります。 これは、2つのブラウザーに実装されているストレージアクセスポリシーの違いが原因です。 Firefox に固有の設計プロパティを以下に要約します。

+ + + +

追跡クッキーをブロックするための Firefox の新しいストレージアクセスポリシーの文書には、ストレージアクセス許可の範囲の詳細な説明が含まれています。

+ +

Storage Access API のメソッド

+ +

Storage Access API のメソッドは、{{domxref("Document")}} インターフェイスに実装されます。

+ +
+
{{domxref("Document.hasStorageAccess()")}}
+
文書がファーストパーティストレージにアクセスできるかどうかを示すブール値で解決される {{jsxref("Promise")}} を返します。
+
{{domxref("Document.requestStorageAccess()")}}
+
ファーストパーティストレージへのアクセスが許可された場合に解決し、アクセスが拒否された場合に拒否する {{jsxref("Promise")}} を返します。
+
+ +
+

注: ユーザーとのやり取りは、これらの両方のメソッドによって返される Promise に伝播し、呼び出し元は、ユーザーからの2回目のクリックを必要とせずに、ユーザーとのやり取りを必要とするアクションを実行できます。 例えば、呼び出し元は、Firefox のポップアップブロッカーをトリガーせずに、解決した Promise からポップアップウィンドウを開くことができます。

+
+ +

<iframe> サンドボックスの拡張

+ +

{{htmlelement("iframe")}} 要素の sandbox 属性には新しいトークン allow-storage-access-by-user-activation があり、サンドボックス化した <iframe> は Storage Access API を使用してストレージアクセスを要求できます。

+ +

仕様

+ +

API は現在、提案段階にあり、標準化プロセスはまだ開始されていません。 現在、Apple の Introducing Storage Access API ブログ投稿、および WHATWG HTML issue 3338 — Proposal: Storage Access API で API の仕様の詳細を見つけることができます。

+ +

ブラウザーの互換性

+ + + +

{{Compat("api.Document.hasStorageAccess")}}

+ +

{{Compat("api.Document.requestStorageAccess")}}

+ +

関連情報

+ +

Storage Access API の使用

diff --git a/files/ja/web/api/storage_access_api/using/index.html b/files/ja/web/api/storage_access_api/using/index.html new file mode 100644 index 0000000000..f6446ab416 --- /dev/null +++ b/files/ja/web/api/storage_access_api/using/index.html @@ -0,0 +1,53 @@ +--- +title: Storage Access API の使用 +slug: Web/API/Storage_Access_API/Using +tags: + - API + - DOM + - Guide + - Reference + - Storage + - Storage Access API +translation_of: Web/API/Storage_Access_API/Using +--- +
{{seecompattable}}{{DefaultAPISidebar("Storage Access API")}}
+ +

埋め込まれたクロスオリジンの文書で Storage Access API を使用して、ファーストパーティストレージにアクセスできるかどうかを確認し、そうでない場合はアクセスを要求する必要があります。 一般的なストレージアクセスのシナリオについて簡単に説明します。

+ +

使用上の注意

+ +

Storage Access API は、ユーザーのブラウザーがすべてのサードパーティのクッキーをブロックするように設定されている場合にブロックされるストレージへのアクセスを埋め込まれたコンテンツが要求できるように設計されています。 埋め込まれたコンテンツはユーザーが使用しているストレージポリシーを認識しないため、ストレージからの読み取りまたは書き込みを試みる前に、常に埋め込まれたフレームにストレージアクセスがあるかどうかを確認するのが最善です。 これは、{{domxref("Document.cookie")}} へのアクセスの場合に特に当てはまります。 サードパーティのクッキーがブロックされると、ブラウザーはしばしば空のクッキージャーを返すためです。

+ +

埋め込まれたクロスオリジン iframe でユーザーのクッキーにアクセスする

+ +

この例では、埋め込まれたクロスオリジン {{htmlelement("iframe")}} が、サードパーティのクッキーをブロックするストレージアクセスポリシーの下でユーザーのクッキーにアクセスする方法を示します。

+ +

まず、<iframe> がサンドボックス化されている場合、次のように、埋め込まれたウェブサイトは allow-storage-access-by-user-activation sandbox トークンを追加して、ストレージアクセス要求が成功することを許可するとともに、allow-scripts と allow-same-origin を使用して API の呼び出しを許可し、クッキーを持つことができるオリジンで実行します。

+ +
<iframe sandbox="allow-storage-access-by-user-activation
+                 allow-scripts
+                 allow-same-origin">
+  ...
+</iframe>
+ +

次に、埋め込まれた文書内で実行されるコードに進みます。 現在ストレージにアクセスできるかどうかはわからないため、最初に {{domxref("Document.hasStorageAccess()")}} を呼び出す必要があります。 その呼び出しが false を返す場合、{{domxref("Document.requestStorageAccess()")}} を呼び出すことができます。 それが返した結果は、前の Promise 呼び出しにチェーンできます。 最後の then では、ファーストパーティストレージへのアクセスが可能になります。

+ +
document.hasStorageAccess().then(hasAccess => {
+  if (!hasAccess) {
+    return document.requestStorageAccess();
+  }
+}).then(_ => {
+  // これで、ファーストパーティストレージにアクセスできます！
+
+  // ファーストパーティのクッキージャーからいくつかのアイテムにアクセスしましょう
+  document.cookie = "foo=bar";              // クッキーを設定
+  localStorage.setItem("username", "John"); // localStorage エントリにアクセス
+}).catch(_ => {
+  // ストレージアクセスの取得エラー。
+});
+ +

埋め込まれたコンテンツがタップやクリックなどのユーザージェスチャーを現在処理していない限り、アクセス要求は自動的に拒否されることに注意してください。 このコードは、例えば、次のようなユーザージェスチャーベースのイベントハンドラー内で実行する必要があります。

+ +
btn.addEventListener('click', () => {
+  // ここでコードを実行します
+});
-- cgit v1.2.3-54-g00ecf