許可リストを使用して、アクセスが事前に承認されている URL を指定する 編集することもできます。許可リストでユーザーを保護 データ許可リストを定義すると、スクリプト プロジェクトは許可リストに登録されている URL には 許可リストに登録されていません。
テストデプロイをインストールする場合、このフィールドは省略できますが、 バージョニングされた Deployment を作成します。
許可リストを使用するのは、スクリプトまたはアドオンが できます。
- 外部の場所(HTTPS など)から情報を取得または取得
Apps Script
UrlFetch
を使用します。 あります。取得対象の URL を許可リストに登録するには、マニフェスト ファイルにurlFetchWhitelist
フィールドを含めます。 - ユーザーの操作に応じて URL を開くか表示する(
外部の URL を開く、または表示する Google Workspace アドオン
。URL を公開用に許可リストに登録するには、
addOns.common.openLinkUrlPrefixes
フィールドを 使用します。
許可リストにプレフィックスを追加する
マニフェスト ファイルで許可リストを指定する(
addOns.common.openLinkUrlPrefixes
または urlFetchWhitelist
フィールドなど)を使用する場合は、
URL プレフィックスのリストを含めることもできます。マニフェストに追加する接頭辞は、
次の要件を満たす必要があります。
- 各接頭辞には有効な URL を指定する必要があります。
- 各プレフィックスでは
http://
ではなくhttps://
を使用する必要があります。 - 各プレフィックスには完全なドメインが必要です。
- 各接頭辞には空でないパスが必要です。例:
https://www.google.com/
は有効ですが、https://www.google.com
は無効です。 - ワイルドカードを使用して、URL サブドメインの接頭辞と照合できます。
- 単一の
*
ワイルドカードをaddOns.common.openLinkUrlPrefixes
フィールドはすべてのリンクに一致しますが、この方法では ユーザーのデータがリスクにさらされ、 アドオンの審査プロセスに進みます。単独 アドオン機能で必要な場合はワイルドカードを使用できます。
URL が許可リストに登録されたプレフィックスと一致するかどうかを判断する際は、次のルールが適用されます。 apply:
- パス マッチングでは大文字と小文字が区別されます。
- プレフィックスが URL と同一の場合は、一致とみなされます。
- URL が接頭辞と同じ、または子である場合は、一致と見なされます。
たとえば、接頭辞 https://example.com/foo
は次の URL と一致します。
https://example.com/foo
https://example.com/foo/
https://example.com/foo/bar
https://example.com/foo?bar
https://example.com/foo#bar
ワイルドカードの使用
1 つのワイルドカード文字(*
)を使用して、両方のサブドメインの
urlFetchWhitelist
および addOns.common.openLinkUrlPrefixes
表示されます。複数のサブドメインに一致させるために複数のワイルドカードを使用することはできません。
ワイルドカードは URL の先頭の接頭辞を表す必要があります。
たとえば、接頭辞 https://*.example.com/foo
は次のように一致します。
URL:
https://subdomain.example.com/foo
https://any.number.of.subdomains.example.com/foo
接頭辞 https://*.example.com/foo
が以下と一致していない
URL:
https://subdomain.example.com/bar
(接尾辞の不一致)https://example.com/foo
(サブドメインが 1 つ以上必要です)
マニフェストを保存しようとすると、一部の接頭辞ルールが適用されます。対象 たとえば、次の接頭辞が名前に含まれる場合、 保存しようとすると、次のことがわかります。
https://*.*.example.com/foo
(複数のワイルドカードは禁止されています)https://subdomain.*.example.com/foo
(先頭の接頭辞としてワイルドカードを使用する必要があります)。