Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Les listes d'autorisation vous permettent de désigner des URL spécifiques qui sont préapprouvées pour l'accès par votre script ou module complémentaire. Les listes d'autorisation permettent de protéger les données utilisateur. Lorsque vous définissez une liste d'autorisation, les projets de script ne peuvent pas accéder aux URL qui n'y ont pas été ajoutées.
Ce champ est facultatif lorsque vous installez un déploiement de test, mais il est obligatoire lorsque vous créez un déploiement versionné.
Vous utilisez des listes d'autorisation lorsque votre script ou votre module complémentaire effectue les actions suivantes :
Récupère des informations à partir d'un emplacement externe (tel que des points de terminaison HTTPS) à l'aide du service UrlFetch Apps Script. Pour autoriser les URL à être récupérées, incluez le champ urlFetchWhitelist dans votre fichier manifeste.
Ouvre ou affiche une URL en réponse à une action de l'utilisateur (obligatoire pour les modules complémentaires Google Workspace qui ouvrent ou affichent des URL externes à Google). Pour autoriser l'ouverture d'URL, incluez le champ addOns.common.openLinkUrlPrefixes dans votre fichier manifeste.
Ajouter des préfixes à votre liste d'autorisation
Lorsque vous spécifiez des listes d'autorisation dans votre fichier manifeste (en incluant le champ addOns.common.openLinkUrlPrefixes ou urlFetchWhitelist), vous devez inclure une liste de préfixes d'URL. Les préfixes que vous ajoutez au fichier manifeste doivent répondre aux exigences suivantes :
Chaque préfixe doit être une URL valide.
Chaque préfixe doit utiliser https://, et non http://.
Chaque préfixe doit comporter un domaine complet.
Chaque préfixe doit comporter un chemin non vide. Par exemple, https://www.google.com/ est valide, mais https://www.google.com ne l'est pas.
Vous pouvez utiliser des caractères génériques pour faire correspondre les préfixes de sous-domaine d'URL.
Un seul caractère générique * peut être utilisé dans le champ addOns.common.openLinkUrlPrefixes pour correspondre à tous les liens, mais cela n'est pas recommandé, car cela peut exposer les données d'un utilisateur à des risques et prolonger le processus d'examen des modules complémentaires. N'utilisez un caractère générique que si la fonctionnalité de votre module complémentaire l'exige.
Les règles suivantes s'appliquent pour déterminer si une URL correspond à un préfixe dans la liste d'autorisation :
La mise en correspondance des chemins d'accès est sensible à la casse.
Si le préfixe est identique à l'URL, il y a correspondance.
Si l'URL est identique au préfixe ou est un enfant du préfixe, elle correspond.
Par exemple, le préfixe https://example.com/foo correspond aux URL suivantes :
https://example.com/foo
https://example.com/foo/
https://example.com/foo/bar
https://example.com/foo?bar
https://example.com/foo#bar
Utiliser des caractères génériques
Vous pouvez utiliser un seul caractère générique (*) pour faire correspondre un sous-domaine pour les champs urlFetchWhitelist et addOns.common.openLinkUrlPrefixes. Vous ne pouvez pas utiliser plusieurs caractères génériques pour faire correspondre plusieurs sous-domaines. De plus, le caractère générique doit représenter le préfixe de début de l'URL.
Par exemple, le préfixe https://*.example.com/foo correspond aux URL suivantes :
https://subdomain.example.com/foo
https://any.number.of.subdomains.example.com/foo
Le préfixe https://*.example.com/foone correspond pas aux URL suivantes :
https://example.com/foo (au moins un sous-domaine doit être présent)
Certaines règles de préfixe sont appliquées lorsque vous essayez d'enregistrer votre fichier manifeste. Par exemple, les préfixes suivants entraînent une erreur s'ils sont présents dans votre fichier manifeste lorsque vous tentez d'enregistrer :
https://*.*.example.com/foo (plusieurs caractères génériques sont interdits)
https://subdomain.*.example.com/foo
(les caractères génériques doivent être utilisés comme préfixe)
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/08/31 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Il n'y a pas l'information dont j'ai besoin","missingTheInformationINeed","thumb-down"],["Trop compliqué/Trop d'étapes","tooComplicatedTooManySteps","thumb-down"],["Obsolète","outOfDate","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Mauvais exemple/Erreur de code","samplesCodeIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 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)"]]
