Jetzt mit KI-gestütztem Page Building über den MCP-Server

Konto

Was dein Plan gewährt, welche Limits gelten und wie Rollen entscheiden, wer was darf.

Ein Workspace trägt einen Plan, eine Reihe von Limits und eine Mitgliederliste. Alle drei sind programmatisch lesbar - Grund genug, sie zu verstehen, statt sie im falschen Moment zu entdecken.

Plan und Limits

Jeder Workspace meldet seinen Plan und die zugehörigen Obergrenzen:

{
  "name": "Acme",
  "slug": "acme",
  "plan": "enterprise",
  "limits": {
    "maxPages": 999999,
    "maxMembers": 999999,
    "maxWorkspaces": 999999,
    "maxStorageMb": 999999,
    "maxAiTokensMonth": 999999,
    "maxApiRequestsMonth": 999999999,
    "maxBandwidthGbMonth": 999999,
    "canRemoveBranding": true,
    "canUseCart": true
  }
}

Diese Zahlen stammen aus einem Enterprise-Workspace, wo die Obergrenzen so hoch gesetzt sind, dass sie praktisch unbegrenzt wirken. Kleinere Pläne liefern echte Werte - genau deshalb liest man sie aus, statt eine Annahme fest zu verdrahten.

Zwei Arten von Dingen stecken darin. Obergrenzen - Seiten, Mitglieder, Speicher, KI-Tokens, API-Requests, Bandbreite - sind Mengen, die sich erschöpfen lassen. Fähigkeits-Flags - canRemoveBranding, canUseCart - sind Funktionen, die an oder aus sind.

Lies sie, statt sie anzunehmen. Ein Build-Schritt, der Seiten anlegt, oder ein Skript, das Medien massenhaft hochlädt, sollte die Grenze kennen, unter der es arbeitet.

Das Delivery-Limit scheitert verwirrend

Überschreite das monatliche Delivery-Kontingent, und public.siteConfig antwortet nicht mehr. Deine Site verhält sich dann genau so, als wäre der Workspace-Slug falsch oder das Netz weg.

Deshalb unterscheidet der Preflight von cmssy link die drei Fälle, statt ein einziges „Workspace nicht erreichbar“ zu melden. Wenn deine Site plötzlich nichts mehr lädt und sich an der Config nichts geändert hat: erst die Nutzung prüfen, dann DNS.

Rollen

Berechtigungen sind als ressource:aktion benannt - pages:view, media:upload, forms:submissions:manage, workspace:billing. Eine Rolle ist ein benanntes Bündel davon.

Rollen tragen zwei bemerkenswerte Flags:

  • isSystem - eingebaut und nicht editierbar. Owner ist die Systemrolle und hält *: jede Berechtigung, auch künftige. Genau das ist der Sinn des Wildcards - ein neues Feature erfordert kein Update der Owner-Rolle.
  • isDefault - die Rolle, die neue Mitglieder erhalten. Setze sie bewusst; was sie hält, gewährt eine Einladung, bevor jemand sie prüft.

Team-Rollen und Mitglieds-Rollen sind Verschiedenes

Ein Workspace kann eine Rolle ganz ohne Berechtigungen halten - typischerweise Customer genannt. Das ist keine Fehlkonfiguration.

Site-Mitglieder, die sich auf deiner öffentlichen Seite anmelden, sind etwas anderes als die Leute, die sie bearbeiten. Eine Mitglieds-Rolle existiert, um diese Besucher zu benennen und zu gruppieren; sie gewährt im Workspace nichts, weil ein Kunde deines Shops im CMS nichts verloren hat. Team-Rollen gewähren Workspace-Rechte; Mitglieds-Rollen identifizieren Zielgruppen.

Beides zu verwechseln ist der Weg, auf dem eine Kundenrolle leise pages:edit bekommt.

Die Granularität ist Absicht

Die Berechtigungsliste trennt Dinge, die man zusammen erwarten würde. pages:edit und pages:publish sind getrennt - du kannst jemanden schreiben lassen, ohne ihn veröffentlichen zu lassen. forms:view und forms:submissions:view sind getrennt - ein Kontaktformular zu bauen verlangt nicht, zu lesen, was Leute darin abgeschickt haben.

Nimm die Trennung beim Zusammenstellen von Rollen ernst. Die naheliegende Versuchung ist, ganze Namensräume zu vergeben - und in dem Moment werden „darf Texte bearbeiten“ und „darf Kundennachrichten lesen“ dieselbe Vergabe.

Nächste Schritte