許可清單網址
透過集合功能整理內容
你可以依據偏好儲存及分類內容。
您可以使用允許清單指定預先核准的網址,供指令碼或外掛程式存取。許可清單有助於保護使用者資料。定義許可清單後,指令碼專案就無法存取未加入許可清單的網址。
安裝測試部署時,這個欄位為選填,但建立版本化部署時則為必填。
當指令碼或外掛程式執行下列動作時,您可以使用許可清單:
在許可清單中新增前置字串
在資訊清單檔案中指定允許清單時 (加入 addOns.common.openLinkUrlPrefixes
或 urlFetchWhitelist
欄位),必須加入網址前置字元清單。您在資訊清單中新增的前置字元必須符合下列規定:
- 每個前置字串都必須是有效的網址。
- 每個前置字串都必須使用
https://
,而非 http://
。
- 每個前置字元都必須有完整網域。
- 每個前置字串都必須有非空白路徑。舉例來說,
https://www.google.com/
有效,但 https://www.google.com
無效。
- 您可以使用萬用字元比對網址子網域前置字元。
- 您可以在
addOns.common.openLinkUrlPrefixes
欄位中使用單一 *
萬用字元來比對所有連結,但我們不建議這麼做,因為這可能會讓使用者資料暴露於風險中,並延長外掛程式審查程序。只有在外掛程式功能需要時,才使用萬用字元。
判斷網址是否與允許清單中的前置字元相符時,適用下列規則:
- 路徑比對會區分大小寫。
- 如果前置字元與網址完全相同,即為相符。
- 如果網址與前置字串相同或為其子項,即為相符。
舉例來說,前置字元 https://example.com/foo
會比對下列網址:
https://example.com/foo
https://example.com/foo/
https://example.com/foo/bar
https://example.com/foo?bar
https://example.com/foo#bar
使用萬用字元
您可以在 urlFetchWhitelist
和 addOns.common.openLinkUrlPrefixes
欄位中使用單一萬用字元 (*
) 比對子網域。您無法使用多個萬用字元比對多個子網域,且萬用字元必須代表網址的前置字元前置字元。
舉例來說,前置字元 https://*.example.com/foo
會比對下列網址:
https://subdomain.example.com/foo
https://any.number.of.subdomains.example.com/foo
前置字元 https://*.example.com/foo
不符合下列網址:
https://subdomain.example.com/bar
(後置字串不符)
https://example.com/foo
(至少須有一個子網域)
嘗試儲存資訊清單時,系統會強制執行部分前置字元規則。舉例來說,如果您嘗試儲存資訊清單,但其中包含下列前置字元,就會發生錯誤:
https://*.*.example.com/foo
(禁止使用多個萬用字元)
https://subdomain.*.example.com/foo
(萬用字元必須做為前置字串)
除非另有註明,否則本頁面中的內容是採用創用 CC 姓名標示 4.0 授權,程式碼範例則為阿帕契 2.0 授權。詳情請參閱《Google Developers 網站政策》。Java 是 Oracle 和/或其關聯企業的註冊商標。
上次更新時間:2025-08-31 (世界標準時間)。
[null,null,["上次更新時間:2025-08-31 (世界標準時間)。"],[[["\u003cp\u003eAllowlists specify approved URLs for your script or add-on to access, enhancing user data protection by restricting access to unlisted URLs.\u003c/p\u003e\n"],["\u003cp\u003eAllowlists are necessary for scripts that fetch external data or open external links, especially for versioned deployments and Google Workspace Add-ons.\u003c/p\u003e\n"],["\u003cp\u003eWhen defining allowlists, use HTTPS prefixes with full domains, non-empty paths, and optional wildcards for subdomains, ensuring adherence to specific formatting rules.\u003c/p\u003e\n"],["\u003cp\u003eAllowlist prefixes are matched against URLs based on case-sensitive path comparisons, allowing access to identical URLs or child paths of the prefix.\u003c/p\u003e\n"],["\u003cp\u003eWildcards can represent subdomains in allowlist prefixes but must be used as the leading prefix and cannot be used to match multiple subdomains simultaneously.\u003c/p\u003e\n"]]],[],null,["# Allowlist URLs\n\nYou use allowlists to designate specific URLs that are pre-approved for access\nby your script or add-on. Allowlists help protect user\ndata; when you define an allowlist, script projects can't access URLs that have\nnot been added to the allowlist.\n\nThis field is optional when you install a test deployment, but is required when\nyou create a versioned deployment.\n\nYou use allowlists when your script or add-on performs\nthe following actions:\n\n- Retrieves or fetches information from an external location (such as HTTPS endpoints) using the Apps Script [`UrlFetch`](/apps-script/reference/url-fetch) service. To allowlist URLs for fetching, include the [`urlFetchWhitelist`](/apps-script/manifest#Manifest.FIELDS.urlFetchWhitelist) field in your manifest file.\n- Opens or displays a URL in response to a user action (Required for Google Workspace add-ons that open or display URLs that are external to Google). To allowlist URLs for opening, include the [`addOns.common.openLinkUrlPrefixes`](/apps-script/manifest/addons#Common.FIELDS.openLinkUrlPrefixes) field in your manifest file.\n\n| **Note:** *Whitelist* , as used in [`urlFetchWhitelist`](/apps-script/manifest#Manifest.FIELDS.urlFetchWhitelist), is a deprecated term that is synonymous with and replaced by *allowlist* . For more information, see [Writing inclusive documentation](https://developers.google.com/style/inclusive-documentation).\n\n### Adding prefixes to your allowlist\n\nWhen you specify allowlists in your manifest file (by including either the\n`addOns.common.openLinkUrlPrefixes` or `urlFetchWhitelist` field), you must\ninclude a list of URL prefixes. The prefixes you add to the manifest must\nsatisfy the following requirements:\n\n- Each prefix must be a valid URL.\n- Each prefix must use `https://`, not `http://`.\n- Each prefix must have a full domain.\n- Each prefix must have a non-empty path. For example, `https://www.google.com/` is valid but `https://www.google.com` is not.\n- You can use [wildcards](#using_wildcards) to match URL subdomain prefixes.\n- A single `*` wildcard can be used in the [`addOns.common.openLinkUrlPrefixes`](/apps-script/manifest/addons#Common.FIELDS.openLinkUrlPrefixes) field to match all links, but this is not recommended as it can expose a user's data to risk and can prolong the [add-on review](/workspace/add-ons/concepts/gsuite-addon-review) process. Only use a wildcard if your add-on functionality requires it.\n\nWhen determining if a URL matches a prefix in the allowlist, the following rules\napply:\n\n- Path matching is case-sensitive.\n- If the prefix is identical to the URL, it is a match.\n- If the URL is the same or a child of the prefix, it is a match.\n\nFor example, the prefix `https://example.com/foo` matches the following URLs:\n\n- `https://example.com/foo`\n- `https://example.com/foo/`\n- `https://example.com/foo/bar`\n- `https://example.com/foo?bar`\n- `https://example.com/foo#bar`\n\n### Using wildcards\n\nYou can use a single wildcard character (`*`) to match a subdomain for both the\n[`urlFetchWhitelist`](/apps-script/manifest#Manifest.FIELDS.urlFetchWhitelist)\nand [`addOns.common.openLinkUrlPrefixes`](/apps-script/manifest/addons#Common.FIELDS.openLinkUrlPrefixes)\nfields. You can't use more than one wildcard to match multiple subdomains, and\nthe wildcard must represent the leading prefix of the URL.\n\nFor example, the prefix `https://*.example.com/foo` matches the following\nURLs:\n\n- `https://subdomain.example.com/foo`\n- `https://any.number.of.subdomains.example.com/foo`\n\nThe prefix `https://*.example.com/foo` *doesn't* match the following\nURLs:\n\n- `https://subdomain.example.com/bar` (suffix mismatch)\n- `https://example.com/foo` (at least one subdomain must be present)\n\nSome of the prefix rules are enforced when you try to save your manifest. For\nexample, the following prefixes cause an error if they are present in your\nmanifest when you attempt to save:\n\n- `https://*.*.example.com/foo` (multiple wildcards are forbidden)\n- `https://subdomain.*.example.com/foo` (wildcards must be used as a leading prefix)"]]