Zadbaj o dobrą organizację dzięki kolekcji
Zapisuj i kategoryzuj treści zgodnie ze swoimi preferencjami.
Listy dozwolonych służą do wyznaczania konkretnych adresów URL, które są wstępnie zatwierdzone do dostępu przez skrypt lub dodatek. Listy dozwolonych pomagają chronić dane użytkowników. Gdy zdefiniujesz listę dozwolonych, projekty skryptów nie będą mieć dostępu do adresów URL, które nie zostały dodane do tej listy.
To pole jest opcjonalne podczas instalowania wdrożenia testowego, ale wymagane podczas tworzenia wdrożenia z określoną wersją.
Listy dozwolonych są używane, gdy skrypt lub dodatek wykonuje te działania:
Pobiera informacje z zewnętrznej lokalizacji (np. punktów końcowych HTTPS) za pomocą usługi Apps Script UrlFetch. Aby dodać adresy URL do listy dozwolonych na potrzeby pobierania, w pliku manifestu umieść pole urlFetchWhitelist.
Otwiera lub wyświetla adres URL w odpowiedzi na działanie użytkownika (wymagane w przypadku dodatków do Google Workspace, które otwierają lub wyświetlają adresy URL zewnętrzne w stosunku do Google). Aby dodać adresy URL do listy dozwolonych w celu otwierania, uwzględnij w pliku manifestu pole addOns.common.openLinkUrlPrefixes.
Dodawanie prefiksów do listy dozwolonych
Gdy określasz listy dozwolonych w pliku manifestu (dodając pole addOns.common.openLinkUrlPrefixes lub urlFetchWhitelist), musisz podać listę prefiksów adresów URL. Prefiksy dodane do pliku manifestu muszą spełniać te wymagania:
Każdy prefiks musi być prawidłowym adresem URL.
Każdy prefiks musi używać znaku https://, a nie http://.
Każdy prefiks musi zawierać pełną domenę.
Każdy prefiks musi mieć niepustą ścieżkę. Na przykład wartość https://www.google.com/ jest prawidłowa, ale https://www.google.com już nie.
W polu addOns.common.openLinkUrlPrefixes można użyć pojedynczego symbolu wieloznacznego *, aby dopasować wszystkie linki, ale nie jest to zalecane, ponieważ może narazić dane użytkownika na ryzyko i wydłużyć proces weryfikacji dodatku. Symbolu wieloznacznego używaj tylko wtedy, gdy jest to wymagane przez funkcje dodatku.
Podczas sprawdzania, czy adres URL pasuje do prefiksu na liście dozwolonych, obowiązują te reguły:
W dopasowaniu ścieżki jest rozróżniana wielkość liter.
Jeśli prefiks jest identyczny z adresem URL, następuje dopasowanie.
Jeśli adres URL jest taki sam jak prefiks lub jest jego elementem podrzędnym, następuje dopasowanie.
Na przykład prefiks https://example.com/foo pasuje do tych adresów URL:
https://example.com/foo
https://example.com/foo/
https://example.com/foo/bar
https://example.com/foo?bar
https://example.com/foo#bar
Używanie symboli wieloznacznych
Aby dopasować subdomenę w polach urlFetchWhitelist i addOns.common.openLinkUrlPrefixes, możesz użyć pojedynczego symbolu wieloznacznego (*). Nie możesz używać więcej niż jednego symbolu wieloznacznego do dopasowywania wielu subdomen, a symbol wieloznaczny musi reprezentować prefiks adresu URL.
Na przykład prefiks https://*.example.com/foo pasuje do tych adresów URL:
https://subdomain.example.com/foo
https://any.number.of.subdomains.example.com/foo
Prefiks https://*.example.com/foonie pasuje do tych adresów URL:
https://example.com/foo (musi być co najmniej 1 subdomena)
Niektóre reguły dotyczące prefiksów są egzekwowane podczas próby zapisania pliku manifestu. Na przykład te prefiksy powodują błąd, jeśli znajdują się w pliku manifestu podczas próby zapisania:
https://*.*.example.com/foo (wiele symboli wieloznacznych jest niedozwolonych)
https://subdomain.*.example.com/foo
(symbole wieloznaczne muszą być używane jako prefiks)
[[["Łatwo zrozumieć","easyToUnderstand","thumb-up"],["Rozwiązało to mój problem","solvedMyProblem","thumb-up"],["Inne","otherUp","thumb-up"]],[["Brak potrzebnych mi informacji","missingTheInformationINeed","thumb-down"],["Zbyt skomplikowane / zbyt wiele czynności do wykonania","tooComplicatedTooManySteps","thumb-down"],["Nieaktualne treści","outOfDate","thumb-down"],["Problem z tłumaczeniem","translationIssue","thumb-down"],["Problem z przykładami/kodem","samplesCodeIssue","thumb-down"],["Inne","otherDown","thumb-down"]],["Ostatnia aktualizacja: 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)"]]
