あなたが CodePen ユーザーであれば、この問題を解決している間、コンソールにノイズが発生する可能性があることを除けば、影響はありません。続ける!
CodePen では、次の図に示す埋め込みペンを用意しています。 。これらには、配置場所と同じオリジン URL ではないユーザー作成のコードが含まれています。私たちは両方になりたいです 安全 そして できるだけ寛容な ユーザーが構築してテストできるようにするものです。
の sandbox
属性は安全性に役立ちます。この属性にはいくつかの問題がありますが、後で説明しますが、これは主に allow
属性。
ここに例を示します。
ユーザーが使用したいのは、 navigator.clipboard.writeText()
API。そこで彼らは次のような JavaScript を書きます。
button.onclick = async () => {
try {
await navigator.clipboard.writeText(`some text`);
console.log('Content copied to clipboard');
} catch (err) {
console.error('Failed to copy: ', err);
}
}
埋め込みペンは、次のような任意の原点に配置されます。 chriscoyier.net
。の src
の にあります
codepen.io
、つまり、そこに原点の不一致があります。 iframe内のJavaScriptは ない したがって、同一生成元の JavaScript はアクセス許可ポリシーの対象となります。
CodePen がそうなったら ない を使用してください allow
私たちの属性 ユーザーがその JavaScript を実行しようとすると、エラーがスローされます。
Failed to copy: NotAllowedError: Failed to execute 'writeText' on 'Clipboard': The Clipboard API has been blocked because of a permissions policy applied to the current document. See https://crbug.com/414348233 for more details.
これは簡単な修正です。私たちはそれを確実にします allow
属性 は で 、次のように、任意のオリジンで許可したい正確な機能をターゲットにします。
しかし、ここで問題が発生します…
(新しい) ネストされた Iframe の問題
CodePenには埋め込みペンがあり、実際にはネストされています 次のような構造になります。

コード構造は次のようになります。
を置く必要があります allow
ユーザー作成のコードに属性を追加すると、次のように機能します。
CodePen UI
User-Authored Code
これが問題です!
すぐに 入れ子になった iframe には allowed 属性があり、最近 (Chrome 136 のようです) ではエラーがスローされます。
[Violation] Potential permissions policy violation: clipboard-write is not allowed in this document.
完全なリスト (以下に記載します) を使用すると、このエラー リストは非常に強力になります。

allow
両方の属性
は?
を置くことはできませんか はい、いいえ。
今、私たちは次のことに遭遇します。 2番目の問題 私たちは何年も取り組んできました。
問題は、どのブラウザにも 違う のセット allow
がサポートする属性値。という値を使用すると、 そうではありません サポートされている場合、それらの属性に関するコンソール エラーまたは警告がスローされます。これは、自分自身のコードが問題の原因であると考える可能性のあるユーザーにとって、騒々しい、または恐ろしいものであり、ユーザー (または私たち) の制御の範囲外です。
allow
Google Chrome の値
のリスト ユーザーがブラウザ API をテストできるようにするには、これらすべてが必要であることはわかっています。このリストは、新しい API を使用して常に調整されており、多くの場合、ユーザーが直接要求します。
そこには、まったく新しいブラウザー API を反映した、まったく新しい AI 関連の属性もいくつかあります。
allow
値のエラー
の例 それらを発送するとしたら allow
すべての属性値
埋め込みペン用に生成したものは、Firefox では次のようになります。

現時点では、Safari ではサポートされていないものに関するエラーや警告は表示されません。 allow
属性値ですが、過去にはあったと思います。
Chrome 自体が警告をスローします。次のような不明なポリシーを含めると、 fartsandwich
、次のような警告がスローされます。
Unrecognized feature: 'fartsandwich'.
これらの AI 関連の属性には、警告もスローされるトライアルが必要なので、ほとんどのユーザーも同様にノイズを受け取ります。

私たちは (ごめん!) ユーザーエージェントスニッフィングを行う必要がある
このようなノイズをすべて回避し、ユーザーを怖がらせるのを防ぐために、ユーザー エージェント (クライアント側) を検出し、それがどのブラウザであると確信しているかに基づいて iframe 属性を生成します。現在のデータと選択肢は次のとおりです。 allow
属性
export default {
allowAttributes: {
chrome: [
'accelerometer',
'bluetooth',
'camera',
'clipboard-read',
'clipboard-write',
'display-capture',
'encrypted-media',
'geolocation',
'gyroscope',
'language-detector',
'language-model',
'microphone',
'midi',
'rewriter',
'serial',
'summarizer',
'translator',
'web-share',
'writer',
'xr-spatial-tracking'
],
firefox: [
'camera',
'display-capture',
'geolocation',
'microphone',
'web-share'
],
default: [
'accelerometer',
'ambient-light-sensor',
'camera',
'display-capture',
'encrypted-media',
'geolocation',
'gyroscope',
'microphone',
'midi',
'payment',
'serial',
'vr',
'web-share',
'xr-spatial-tracking'
]
}
};
私たちは、ユーザー エージェントのスニッフィングには問題が山積していることを十分に長く知っています。また、問題を解決するためにやるべきことをやらなければならないほど長く続きます。私たちはこれを長年にわたって行っており、気に入っているわけではありませんが、ほとんどうまくいっていました。
ユーザー エージェント スニッフィングがクライアントで発生する
CodePen にはいくつかの機能があります。
生成されるのではなく、直接提供されます。
- 直接
埋め込みます。ユーザーは、JavaScript を実行するページ上で直接 JavaScript を実行できない状況 (RSS、制限付き CMS など) でこれを選択します。 - o埋め込みAPI。これにより返されるのは、
サーバー側の呼び出しを介して埋め込まれます。
埋め込みのネストされた構造は、ユーザー エージェントのスニッフィングと正しい適用の実行を試みる最初のレベルの iframe があるここで役に立ちます。 allow
内部 iframe への属性。
ここでの問題は、 allow
属性を直接知ることはできません どのセット 提供する属性の数が少ないため、 世界中のどのブラウザでも その iframe を読み込んでいる可能性があります。
解決策は?
allow
「親」iframe の属性は本当に必要ですか?
は これは退行だったのでしょうか?または これは特徴ですか? 問題は、ネストされた iframe が親に対するアクセス許可を緩める可能性があることのようですが、これはセキュリティ上の問題になる可能性がありますか?ここで私たちがどこに当てはまるのかを知ることは良いことです。
ブラウザーは、サポートされていない許可属性に関するエラーや警告を停止することができるでしょうか?
それがSafariがやっていることのようですが、それで大丈夫でしょうか?
この場合、完全なセットを発送することができます。 allow
すべてのブラウザに対する属性。少し冗長ですが、ユーザーエージェントがスニッフィングする必要がなくなります。
これは、これらの属性に「追いつく」必要があるという問題にも同様に役立つ可能性があります。たとえば、Firefox が「rewriter」値のサポートを開始すると、そのまま動作し始めます。これは、当惑したり失望したユーザーがそれについてサポートするために書き込みをするよりも優れています。 Web プラットフォームのニュースにかなり関心を持っているにもかかわらず、これらの非常にニッチな機能がいつ進化し、iframe 属性の変更が必要になるかを把握するのは難しいことがわかります。
allow
属性はサポートされていますか?
ブラウザは私たちに何への API アクセスを提供できるでしょうか ブラウザがサポートするものを教えてくれるだけで、それに対してリストを検証できるでしょうか? Navigator.allow
?
また…
- それだけではありません
allow
属性。また、ブラウザ固有のセットも保守しています。sandbox
属性。現時点では、これはネストの問題の影響を受けていませんが、その方向に進む可能性があります。 - これはネストされた iframe だけに関するものではありません。どこでも 1 つのレベルの iframe を使用します
codepen.io
ペンのプレビューを表示します。allow
属性もあります。ユーザー エージェント スニッフィング JS にアクセスして正しく処理できるため、これは差し迫った問題ではありませんが、理想的にはそれをまったく行う必要がありません。
Views: 0