Mantieni tutto organizzato con le raccolte
Salva e classifica i contenuti in base alle tue preferenze.
Utilizzi le liste consentite per designare URL specifici pre-approvati per l'accesso
dal tuo script o componente aggiuntivo. Le liste consentite contribuiscono a proteggere i dati degli utenti. Quando definisci una lista consentita, i progetti di script non possono accedere agli URL che non sono stati aggiunti alla lista consentita.
Questo campo è facoltativo quando installi un deployment di test, ma è obbligatorio quando
crei un deployment con controllo delle versioni.
Utilizzi le liste consentite quando lo script o il componente aggiuntivo esegue
le seguenti azioni:
Recupera o estrae informazioni da una posizione esterna (ad esempio endpoint HTTPS) utilizzando il servizio UrlFetch di Apps Script. Per inserire gli URL nella lista consentita per il recupero, includi il campo urlFetchWhitelist nel file manifest.
Apre o visualizza un URL in risposta a un'azione dell'utente (obbligatorio per
i componenti aggiuntivi di Google Workspace che aprono o visualizzano URL esterni a
Google). Per inserire gli URL nella lista consentita per l'apertura, includi il campo addOns.common.openLinkUrlPrefixes nel file manifest.
Aggiungere prefissi alla lista consentita
Quando specifichi le liste consentite nel file manifest (includendo il campo
addOns.common.openLinkUrlPrefixes o urlFetchWhitelist), devi
includere un elenco di prefissi URL. I prefissi che aggiungi al manifest devono
soddisfare i seguenti requisiti:
Ogni prefisso deve essere un URL valido.
Ogni prefisso deve utilizzare https://, non http://.
Ogni prefisso deve avere un dominio completo.
Ogni prefisso deve avere un percorso non vuoto. Ad esempio, https://www.google.com/
è valido, mentre https://www.google.com non lo è.
Puoi utilizzare i caratteri jolly per trovare una corrispondenza con i prefissi dei sottodomini degli URL.
È possibile utilizzare un singolo carattere jolly * nel campo
addOns.common.openLinkUrlPrefixes per trovare corrispondenze con tutti i link, ma questa operazione non è consigliata in quanto può esporre i dati di un utente a rischi e può prolungare la procedura di
revisione dei componenti aggiuntivi. Utilizza
un carattere jolly solo se la funzionalità del componente aggiuntivo lo richiede.
Quando viene determinato se un URL corrisponde a un prefisso nella lista consentita, si applicano le seguenti regole:
La corrispondenza del percorso è sensibile alle maiuscole.
Se il prefisso è identico all'URL, si tratta di una corrispondenza.
Se l'URL è uguale o un elemento secondario del prefisso, si verifica una corrispondenza.
Ad esempio, il prefisso https://example.com/foo corrisponde ai seguenti URL:
https://example.com/foo
https://example.com/foo/
https://example.com/foo/bar
https://example.com/foo?bar
https://example.com/foo#bar
Utilizzo dei caratteri jolly
Puoi utilizzare un singolo carattere jolly (*) per trovare una corrispondenza con un sottodominio per i campi
urlFetchWhitelist
e addOns.common.openLinkUrlPrefixes. Non puoi utilizzare più di un carattere jolly per trovare corrispondenze con più sottodomini e
il carattere jolly deve rappresentare il prefisso iniziale dell'URL.
Ad esempio, il prefisso https://*.example.com/foo corrisponde ai seguenti
URL:
https://subdomain.example.com/foo
https://any.number.of.subdomains.example.com/foo
Il prefisso https://*.example.com/foonon corrisponde ai seguenti
URL:
https://subdomain.example.com/bar (suffisso non corrispondente)
https://example.com/foo (deve essere presente almeno un sottodominio)
Alcune regole relative ai prefissi vengono applicate quando tenti di salvare il manifest. Ad esempio, i seguenti prefissi causano un errore se sono presenti nel manifest quando tenti di salvare:
https://*.*.example.com/foo (sono vietati più caratteri jolly)
https://subdomain.*.example.com/foo
(i caratteri jolly devono essere utilizzati come prefisso iniziale)
[[["Facile da capire","easyToUnderstand","thumb-up"],["Il problema è stato risolto","solvedMyProblem","thumb-up"],["Altra","otherUp","thumb-up"]],[["Mancano le informazioni di cui ho bisogno","missingTheInformationINeed","thumb-down"],["Troppo complicato/troppi passaggi","tooComplicatedTooManySteps","thumb-down"],["Obsoleti","outOfDate","thumb-down"],["Problema di traduzione","translationIssue","thumb-down"],["Problema relativo a esempi/codice","samplesCodeIssue","thumb-down"],["Altra","otherDown","thumb-down"]],["Ultimo aggiornamento 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)"]]