Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
Você usa listas de permissões para designar URLs específicos que são pré-aprovados para acesso
pelo seu script ou complemento. As listas de permissões ajudam a proteger os dados dos usuários. Quando você define uma lista de permissões, os projetos de script não podem acessar URLs que não foram adicionados a ela.
Esse campo é opcional ao instalar uma implantação de teste, mas é obrigatório ao
criar uma implantação com controle de versões.
Você usa listas de permissão quando seu script ou complemento realiza
as seguintes ações:
Recupera ou busca informações de um local externo (como endpoints HTTPS) usando o serviço UrlFetch
do Apps Script. Para permitir URLs para busca, inclua o campo urlFetchWhitelist no arquivo de manifesto.
Abre ou mostra um URL em resposta a uma ação do usuário. Obrigatório para
complementos do Google Workspace que abrem ou mostram URLs externos ao
Google. Para permitir URLs para abertura, inclua o campo addOns.common.openLinkUrlPrefixes no
arquivo de manifesto.
Adicionar prefixos à lista de permissões
Ao especificar listas de permissões no arquivo de manifesto (incluindo o campo addOns.common.openLinkUrlPrefixes ou urlFetchWhitelist), é necessário incluir uma lista de prefixos de URL. Os prefixos adicionados ao manifesto precisam atender aos seguintes requisitos:
Cada prefixo precisa ser um URL válido.
Cada prefixo precisa usar https://, não http://.
Cada prefixo precisa ter um domínio completo.
Cada prefixo precisa ter um caminho não vazio. Por exemplo, https://www.google.com/
é válido, mas https://www.google.com não é.
Você pode usar caracteres curinga para corresponder a prefixos de subdomínio de URL.
Um único caractere curinga * pode ser usado no campo
addOns.common.openLinkUrlPrefixes
para corresponder a todos os links, mas isso não é recomendado porque pode expor os dados de um
usuário a riscos e prolongar o processo de
revisão de complementos. Use um caractere curinga apenas se a funcionalidade do complemento exigir.
Ao determinar se um URL corresponde a um prefixo na lista de permissões, as seguintes regras são aplicadas:
A correspondência de caminhos diferencia maiúsculas de minúsculas.
Se o prefixo for idêntico ao URL, será uma correspondência.
Se o URL for igual ou um filho do prefixo, será uma correspondência.
Por exemplo, o prefixo https://example.com/foo corresponde aos seguintes URLs:
https://example.com/foo
https://example.com/foo/
https://example.com/foo/bar
https://example.com/foo?bar
https://example.com/foo#bar
Como usar caracteres curinga
Você pode usar um único caractere curinga (*) para corresponder a um subdomínio nos campos
urlFetchWhitelist
e addOns.common.openLinkUrlPrefixes. Não é possível usar mais de um caractere curinga para corresponder a vários subdomínios, e
o caractere curinga precisa representar o prefixo inicial do URL.
Por exemplo, o prefixo https://*.example.com/foo corresponde aos seguintes
URLs:
https://subdomain.example.com/foo
https://any.number.of.subdomains.example.com/foo
O prefixo https://*.example.com/foonão corresponde aos seguintes URLs:
https://example.com/foo (pelo menos um subdomínio precisa estar presente)
Algumas das regras de prefixo são aplicadas quando você tenta salvar o manifesto. Por exemplo, os seguintes prefixos causam um erro se estiverem presentes no manifesto quando você tenta salvar:
https://*.*.example.com/foo (não é permitido usar vários caracteres curinga)
https://subdomain.*.example.com/foo
(os caracteres curinga precisam ser usados como um prefixo inicial)
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Não contém as informações de que eu preciso","missingTheInformationINeed","thumb-down"],["Muito complicado / etapas demais","tooComplicatedTooManySteps","thumb-down"],["Desatualizado","outOfDate","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Problema com as amostras / o código","samplesCodeIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 2025-08-31 UTC."],[[["\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)"]]