許可リストを使用して、アクセスが事前に承認されている 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/foohttps://example.com/foo/https://example.com/foo/barhttps://example.com/foo?barhttps://example.com/foo#bar
ワイルドカードの使用
1 つのワイルドカード文字（*）を使用して、両方のサブドメインの
urlFetchWhitelist
および addOns.common.openLinkUrlPrefixes
表示されます。複数のサブドメインに一致させるために複数のワイルドカードを使用することはできません。
ワイルドカードは URL の先頭の接頭辞を表す必要があります。
たとえば、接頭辞 https://*.example.com/foo は次のように一致します。
URL:
https://subdomain.example.com/foohttps://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（先頭の接頭辞としてワイルドカードを使用する必要があります）。