Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
Mit Zulassungslisten können Sie bestimmte URLs festlegen, die für den Zugriff durch Ihr Script oder Add‑on vorab genehmigt werden. Zulassungslisten tragen zum Schutz von Nutzerdaten bei. Wenn Sie eine Zulassungsliste definieren, können Scriptprojekte nicht auf URLs zugreifen, die nicht in der Zulassungsliste enthalten sind.
Dieses Feld ist optional, wenn Sie eine Testbereitstellung installieren, aber erforderlich, wenn Sie eine versionierte Bereitstellung erstellen.
Sie verwenden Zulassungslisten, wenn Ihr Skript oder Add‑on die folgenden Aktionen ausführt:
Ruft Informationen von einem externen Speicherort (z. B. HTTPS-Endpunkte) mithilfe des Apps Script-Dienstes UrlFetch ab. Wenn Sie URLs für das Abrufen auf die Zulassungsliste setzen möchten, fügen Sie das Feld urlFetchWhitelist in Ihre Manifestdatei ein.
Öffnet oder zeigt eine URL als Reaktion auf eine Nutzeraktion an. Erforderlich für Google Workspace-Add-ons, die URLs öffnen oder anzeigen, die nicht zu Google gehören. Wenn Sie URLs für das Öffnen auf die Zulassungsliste setzen möchten, fügen Sie das Feld addOns.common.openLinkUrlPrefixes in Ihre Manifestdatei ein.
Präfixe zur Zulassungsliste hinzufügen
Wenn Sie Zulassungslisten in Ihrer Manifestdatei angeben (indem Sie entweder das Feld addOns.common.openLinkUrlPrefixes oder urlFetchWhitelist einfügen), müssen Sie eine Liste von URL-Präfixen angeben. Die Präfixe, die Sie dem Manifest hinzufügen, müssen die folgenden Anforderungen erfüllen:
Jeder Präfix muss eine gültige URL sein.
Jedes Präfix muss https:// und nicht http:// verwenden.
Jeder Präfix muss eine vollständige Domain haben.
Jedes Präfix muss einen nicht leeren Pfad haben. Beispiel: https://www.google.com/ ist gültig, https://www.google.com jedoch nicht.
Sie können Platzhalter verwenden, um URL-Subdomainpräfixe abzugleichen.
Im Feld addOns.common.openLinkUrlPrefixes kann ein einzelner Platzhalter * verwendet werden, um alle Links abzugleichen. Dies wird jedoch nicht empfohlen, da dadurch die Daten eines Nutzers gefährdet werden können und sich der Add-on-Überprüfungsprozess verlängern kann. Verwenden Sie nur dann einen Platzhalter, wenn die Add-on-Funktionalität dies erfordert.
Bei der Entscheidung, ob eine URL mit einem Präfix in der Zulassungsliste übereinstimmt, gelten die folgenden Regeln:
Beim Pfadabgleich wird zwischen Groß- und Kleinschreibung unterschieden.
Wenn das Präfix mit der URL identisch ist, liegt eine Übereinstimmung vor.
Wenn die URL mit dem Präfix übereinstimmt oder eine untergeordnete URL des Präfixes ist, liegt eine Übereinstimmung vor.
Das Präfix https://example.com/foo stimmt beispielsweise mit den folgenden URLs überein:
https://example.com/foo
https://example.com/foo/
https://example.com/foo/bar
https://example.com/foo?bar
https://example.com/foo#bar
Platzhalter verwenden
Sie können ein einzelnes Platzhalterzeichen (*) verwenden, um eine Subdomain für die Felder urlFetchWhitelist und addOns.common.openLinkUrlPrefixes abzugleichen. Sie können nicht mehr als einen Platzhalter verwenden, um mehrere Subdomains abzugleichen. Der Platzhalter muss das führende Präfix der URL darstellen.
Das Präfix https://*.example.com/foo stimmt beispielsweise mit den folgenden URLs überein:
https://subdomain.example.com/foo
https://any.number.of.subdomains.example.com/foo
Das Präfix https://*.example.com/foostimmt nicht mit den folgenden URLs überein:
https://subdomain.example.com/bar (Suffix stimmt nicht überein)
https://example.com/foo (mindestens eine Subdomain muss vorhanden sein)
Einige der Präfixregeln werden beim Speichern des Manifests erzwungen. Die folgenden Präfixe verursachen beispielsweise einen Fehler, wenn sie beim Speichern im Manifest vorhanden sind:
https://*.*.example.com/foo (mehrere Platzhalter sind nicht zulässig)
https://subdomain.*.example.com/foo
(Platzhalter müssen als führendes Präfix verwendet werden)
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Benötigte Informationen nicht gefunden","missingTheInformationINeed","thumb-down"],["Zu umständlich/zu viele Schritte","tooComplicatedTooManySteps","thumb-down"],["Nicht mehr aktuell","outOfDate","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Problem mit Beispielen/Code","samplesCodeIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 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)"]]