Organiza tus páginas con colecciones
Guarda y categoriza el contenido según tus preferencias.
Usas listas de entidades permitidas para designar URLs específicas que están previamente aprobadas para el acceso de tu secuencia de comandos o complemento. Las listas de entidades permitidas ayudan a proteger los datos del usuario. Cuando defines una lista de entidades permitidas, los proyectos de secuencias de comandos no pueden acceder a las URLs que no se agregaron a la lista.
Este campo es opcional cuando instalas una implementación de prueba, pero es obligatorio cuando creas una implementación versionada.
Usas listas de entidades permitidas cuando tu secuencia de comandos o complemento realizan las siguientes acciones:
Recupera o extrae información de una ubicación externa (como extremos HTTPS) con el servicio UrlFetch de Apps Script. Para incluir URLs en la lista de entidades permitidas para la recuperación, incluye el campo urlFetchWhitelist en tu archivo de manifiesto.
Abre o muestra una URL en respuesta a una acción del usuario (obligatorio para los complementos de Google Workspace que abren o muestran URLs externas a Google). Para incluir URLs en la lista de entidades permitidas para abrirlas, incluye el campo addOns.common.openLinkUrlPrefixes en tu archivo de manifiesto.
Cómo agregar prefijos a tu lista de entidades permitidas
Cuando especificas listas de entidades permitidas en tu archivo de manifiesto (incluyendo el campo addOns.common.openLinkUrlPrefixes o urlFetchWhitelist), debes incluir una lista de prefijos de URL. Los prefijos que agregues al manifiesto deben satisfacer los siguientes requisitos:
Cada prefijo debe ser una URL válida.
Cada prefijo debe usar https://, no http://.
Cada prefijo debe tener un dominio completo.
Cada prefijo debe tener una ruta de acceso no vacía. Por ejemplo, https://www.google.com/ es válido, pero https://www.google.com no lo es.
Puedes usar comodines para que coincidan los prefijos de subdominio de la URL.
Se puede usar un solo comodín * en el campo addOns.common.openLinkUrlPrefixes para que coincidan todos los vínculos, pero no se recomienda, ya que puede exponer los datos del usuario a riesgos y prolongar el proceso de revisión del complemento. Solo usa un comodín si la funcionalidad de tu complemento lo requiere.
Cuando se determina si una URL coincide con un prefijo en la lista de entidades permitidas, se aplican las siguientes reglas:
La coincidencia de rutas distingue mayúsculas de minúsculas.
Si el prefijo es idéntico a la URL, se considera que hay una coincidencia.
Si la URL es la misma o un elemento secundario del prefijo, se considera que hay coincidencia.
Por ejemplo, el prefijo https://example.com/foo coincide con las siguientes URLs:
https://example.com/foo
https://example.com/foo/
https://example.com/foo/bar
https://example.com/foo?bar
https://example.com/foo#bar
Uso de comodines
Puedes usar un solo carácter comodín (*) para que coincida un subdominio en los campos urlFetchWhitelist y addOns.common.openLinkUrlPrefixes. No puedes usar más de un comodín para hacer coincidir varios subdominios, y el comodín debe representar el prefijo inicial de la URL.
Por ejemplo, el prefijo https://*.example.com/foo coincide con las siguientes URLs:
https://subdomain.example.com/foo
https://any.number.of.subdomains.example.com/foo
El prefijo https://*.example.com/foono coincide con las siguientes URLs:
https://subdomain.example.com/bar (no coincide el sufijo)
https://example.com/foo (debe haber al menos un subdominio)
Algunas de las reglas de prefijo se aplican cuando intentas guardar el manifiesto. Por ejemplo, los siguientes prefijos generan un error si están presentes en tu manifiesto cuando intentas guardarlo:
https://*.*.example.com/foo (se prohíben varios comodines)
https://subdomain.*.example.com/foo
(los comodines deben usarse como prefijo inicial)
[[["Fácil de comprender","easyToUnderstand","thumb-up"],["Resolvió mi problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Falta la información que necesito","missingTheInformationINeed","thumb-down"],["Muy complicado o demasiados pasos","tooComplicatedTooManySteps","thumb-down"],["Desactualizado","outOfDate","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Problema con las muestras o los códigos","samplesCodeIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 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)"]]
