许可名单网址
使用集合让一切井井有条
根据您的偏好保存内容并对其进行分类。
您可以使用许可名单来指定已预先批准可供脚本或插件访问的特定网址。许可名单有助于保护用户数据;定义许可名单后,脚本项目便无法访问未添加到许可名单中的网址。
安装测试部署时,此字段为可选字段;但创建版本化部署时,此字段为必填字段。
当脚本或插件执行以下操作时,您需要使用许可名单:
向许可名单添加前缀
在清单文件中指定许可名单时(通过添加 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
(通配符必须用作前导前缀)
如未另行说明,那么本页面中的内容已根据知识共享署名 4.0 许可获得了许可,并且代码示例已根据 Apache 2.0 许可获得了许可。有关详情,请参阅 Google 开发者网站政策。Java 是 Oracle 和/或其关联公司的注册商标。
最后更新时间 (UTC):2025-08-31。
[null,null,["最后更新时间 (UTC):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)"]]