SpaceRole

SpaceRole ist ein Bündel von Berechtigungen, das einem Mitglied eines Space erteilt wird. Es fasst in einer Ressource zusammen, was mit Content Type, Content und Media getan werden darf (Lesen, Erstellen, Bearbeiten, Löschen, Veröffentlichen), ob Script ausgeführt und verwaltet werden kann und ob auf die Einstellungen des Space zugegriffen werden kann. Filter, die den Berechtigungsumfang einschränken (etwa nur auf einen bestimmten Content Type oder nur auf selbst erstellte Ressourcen), werden ebenfalls innerhalb der SpaceRole festgelegt.

Eine erstellte SpaceRole wird für sich allein noch niemandem zugewiesen. Sie wird einem Mitglied erteilt, indem ein Refer auf diese SpaceRole in das Feld roles der Space Membership eingetragen wird. Ein Mitglied kann mehrere SpaceRole gleichzeitig besitzen. Außerdem wird ein DeliveryAccessToken an genau eine SpaceRole mit den geringstmöglichen Rechten (least-privilege) gebunden, wodurch festgelegt wird, welcher Umfang mit diesem Token ausgeliefert werden kann.

Ressourcenstruktur

Im Folgenden steht die Antwort auf eine Einzelabfrage der SpaceRole "Produkt schreibgeschützt". Neben sys (Systemattribute) enthält sie die Inhaltsattribute contentType, content, media, settings und script, die die Berechtigungen festlegen.

{
  "sys": {
    "id": "3trmXRM3RqbgSnifyg7ObyNrQQbHbm",
    "type": "SpaceRole",
    "space": { "sys": { "id": "HnQ32YiH", "type": "Refer", "targetType": "Space" } },
    "createdBy": { "sys": { "id": "3p4tcFbQRwz503VXdtHXNI5dZH5TVB", "type": "Refer", "targetType": "User" } },
    "createdAt": "2026-06-16T09:53:16.617Z",
    "updatedBy": { "sys": { "id": "3p4tcFbQRwz503VXdtHXNI5dZH5TVB", "type": "Refer", "targetType": "User" } },
    "updatedAt": "2026-06-16T09:53:16.617Z",
    "isLocked": false,
    "version": 1
  },
  "name": "Produkt schreibgeschützt",
  "contentType": { "All": { "Allow": [] } },
  "content": {
    "Read": {
      "Allow": [
        { "contentType": { "sys": { "id": "3trmXRLdJF4GBlAjtcuoZ7Pnxj8dlA", "type": "Refer", "targetType": "ContentType" } } }
      ]
    }
  },
  "media": { "All": { "Allow": [] } },
  "settings": [],
  "script": {}
}

Wichtigste Schlüssel:

• contentType: Berechtigungs-Map für den Content Type selbst (das Schema). Die Berechtigungen zum Lesen, Erstellen, Bearbeiten, Löschen und Veröffentlichen eines Content Type werden je Aktion festgelegt.
• content: Berechtigungs-Map für Content (die Inhaltsdaten). Das obige Beispiel zeigt eine Beschränkung, bei der nur Content eines bestimmten Content Type gelesen werden darf.
• media: Berechtigungs-Map für Media (Dateien und Bilder).
• script: Berechtigungs-Map für Script (deklarative Backend-Endpunkte, die vom Frontend aufgerufen werden). Legt Ausführung (Execute) und Verwaltung (Erstellen, Lesen, Bearbeiten, Löschen) je Aktion fest.
• settings: Ein Array aus Zeichenfolgen, das die Zugriffsberechtigung auf die Einstellungen des Space festlegt. Es ist keine Berechtigungs-Map, sondern führt die Aktionsnamen unmittelbar auf. Vollzugriff ist ["SETTING_ALL"], kein Zugriff auf Einstellungen ist [], und es lassen sich auch nur die benötigten Einstellungen auswählen (siehe settings unten).
• isLocked: Bei true handelt es sich um eine von Weegloo standardmäßig bereitgestellte Rolle (etwa Administrator), die nicht geändert oder gelöscht werden kann.

Systemattribute (sys)

Jede SpaceRole fasst gemeinsame Systemattribute im Objekt sys zusammen. space, createdBy und updatedBy werden in der Refer-Form ({ "sys": { "id", "type": "Refer", "targetType" } }) eingetragen.

SpaceRole ist eine Einstellungsressource ohne Veröffentlichungskonzept. Anders als bei Content und Media enthält sys daher kein publish, archive oder status, sondern nur version. Die version erhöht sich bei jeder Änderung der SpaceRole.

Berechtigungs-Maps: contentType, content, media

contentType, content und media sind jeweils Maps, deren Schlüssel Aktionen sind. Die verwendbaren Aktionen sind Create (Erstellen), Read (Lesen), Edit (Bearbeiten), Delete (Löschen), Publish (Veröffentlichen), Unpublish (Veröffentlichung zurücknehmen), Archive (Archivieren) und Unarchive (Archivierung aufheben); zusätzlich gibt es All, das alle Aktionen auf einmal abdeckt. Eine Aktion namens Save gibt es nicht. Die Berechtigung zum Ändern heißt Edit, und Save ist der Name eines Ereignisses, das ein Webhook abonniert. Der Wert jeder Aktion ist ein Objekt, das Regel-Arrays für Allow (Erlauben) und Deny (Verweigern) enthält.

"content": {
  "Read":   { "Allow": [ /* Regel */ ], "Deny": [ /* Regel */ ] },
  "Edit":   { "Allow": [ /* Regel */ ] }
}

Jedes Regelobjekt (rule) hat optionale Filter, die den Berechtigungsumfang einschränken.

• self: Beschränkt das Ziel, auf das die Regel angewendet wird, auf die Ressource selbst. Hier wird ein Refer eingetragen, das auf die Zielressource verweist. In der contentType-Map bedeutet es genau einen bestimmten Content Type, in der script-Map genau ein bestimmtes Script.
• contentType: Beschränkt auf den Content Type, zu dem dieser Content gehört. Hier wird ein Refer eingetragen, das auf den Content Type verweist.
• createdBy: Beschränkt auf Ressourcen, die von einem bestimmten Benutzer erstellt wurden. Wird in sys.id die Kennung eines bestimmten Benutzers eingetragen, gilt die Regel nur für dessen Ressourcen; mit dem reservierten Wert :self gilt sie nur für Ressourcen, die der aktuell aufrufende Benutzer erstellt hat.
• tag: Beschränkt auf Ressourcen, die mit einem bestimmten Tag versehen sind.

Welcher Filter in welcher Berechtigungs-Map eine Bedeutung hat, ist festgelegt. Tragen Sie einen unpassenden Filter ein, wird das Speichern der Rolle abgelehnt. Denn würde er stillschweigend ignoriert, wäre eine Regel, die Sie für eingeschränkt hielten, eine vollständige Erlaubnis.

• Das Ziel der contentType-Map geben Sie nicht mit contentType, sondern mit self an. Denn es geht darum, den Content Type selbst einzuschränken. Der contentType-Filter bedeutet „die Art, auf die diese Ressource verweist", und passt daher nur zur content-Map.
• Ein Filter, der über eine Achse einschränken will, die es bei dieser Ressource nicht gibt (tag bei einem Content Type, contentType bei einem Media), wird zwar beim Speichern nicht blockiert, aber die Regel wird nicht wie beabsichtigt ausgewertet. Verwenden Sie ihn nicht.

Wenn Sie den createdBy-Filter (einschließlich :self) über CDA (Auslieferung) auswerten, muss publishWithAuthor des betreffenden Content Type true sein. CDA wertet diesen Filter anhand von sys.createdBy im Veröffentlichungs-Snapshot aus; ist publishWithAuthor der Standardwert false, enthält der Snapshot keine Autoreninformationen, sodass die Allow-Regel nichts trifft und die Deny-Regel niemanden herausfiltert. CMA (Verwaltung) wertet anhand von sys.createdBy des Entwurfs aus und ist daher von dieser Einstellung unabhängig. publishWithAuthor wirkt nicht rückwirkend, muss also eingeschaltet werden, bevor der Inhalt veröffentlicht wird, und ein bereits veröffentlichter Content muss erneut veröffentlicht werden. Siehe die Beschreibung von publishWithAuthor bei Content Type.

Ein leeres Allow-Array [] bedeutet, dass die Aktion für die gesamte jeweilige Art erlaubt ist. Da der Filter leer ist, gibt es nichts zu filtern, und die Aktion ist für alle Ressourcen geöffnet.

Ein leeres Deny-Array [] verhält sich umgekehrt. Es bedeutet nicht „nichts wird verweigert", sondern verweigert die gesamte jeweilige Art und blockiert die Aktion damit vollständig. Auch wenn Sie zusätzlich ein Allow angeben, bleibt sie blockiert. Setzen Sie [] in der Annahme, es gebe nichts zu verweigern, tritt genau das Gegenteil ein. Wenn Sie also nichts verweigern wollen, tragen Sie den Schlüssel Deny gar nicht ein.

Beispiel 1: Administrator (Vollzugriff, standardmäßig bereitgestellt)

Die Rolle Administrator erlaubt mit einem leeren Allow auf der Aktion All für contentType, content, media und script jeweils den vollständigen Zugriff und gewährt mit ["SETTING_ALL"] in settings den Zugriff auf sämtliche Einstellungen des Space. Da Weegloo diese Rolle standardmäßig bereitstellt, ist sys.isLocked gleich true und die Rolle kann nicht geändert oder gelöscht werden.

{
  "sys": {
    "id": "3trmXRLdJF4GBlAjtcuoWfVubsasp4",
    "type": "SpaceRole",
    "space": { "sys": { "id": "HnQ32YiH", "type": "Refer", "targetType": "Space" } },
    "createdBy": { "sys": { "id": "_", "type": "Refer", "targetType": "User" } },
    "createdAt": "2026-06-14T14:56:04.737Z",
    "updatedBy": { "sys": { "id": "_", "type": "Refer", "targetType": "User" } },
    "updatedAt": "2026-06-14T14:56:04.737Z",
    "isLocked": true,
    "version": 1
  },
  "name": "Administrator",
  "description": "Members of this role have full access to everything in this space.",
  "contentType": { "All": { "Allow": [] } },
  "content": { "All": { "Allow": [] } },
  "media": { "All": { "Allow": [] } },
  "settings": ["SETTING_ALL"],
  "script": { "All": { "Allow": [] } }
}

Beispiel 2: Schreibgeschützt (nur ein bestimmter Content Type)

Ein Beispiel für eine selbst erstellte least-privilege-Rolle. Es wird nur auf der Aktion Read von content eine Regel gesetzt, und über den Filter contentType dieser Regel wird sie auf genau einen bestimmten Content Type beschränkt. Der Content Type selbst und Media sind mit einem leeren Allow auf All geöffnet, doch bei den Inhaltsdaten ist nur das Lesen dieser einen Art möglich. Da settings gleich [] ist, besteht kein Zugriff auf die Einstellungen des Space. Wird eine solche Rolle an ein DeliveryAccessToken gebunden, liest das Auslieferungs-Token nur diesen Umfang. Das JSON dieser Rolle entspricht der "Produkt schreibgeschützt" aus der obigen Ressourcenstruktur.

settings (Zugriff auf Space-Einstellungen)

settings ist keine Berechtigungs-Map, sondern ein Array aus Zeichenfolgen. Es enthält die Zugriffsberechtigung auf die Einstellungen des Space und kennt weder Allow/Deny noch Filter. Die Aktionen, die im Array stehen, sind erlaubt; die Aktionen, die nicht darin stehen, sind nicht erlaubt.

Vollzugriff ist ["SETTING_ALL"], kein Zugriff wird mit [] ausgedrückt. Wird etwas dazwischen benötigt, wählen Sie aus den folgenden Aktionen aus.

Für die beiden Tokenarten sind die Aktionen getrennt. Wird nur SETTING_DELIVERY_ACCESS_TOKEN erteilt, lässt sich ein schreibgeschütztes Delivery Access Token ausstellen, ein Space Access Token, das auch schreiben kann, jedoch nicht.

Die Aktionen aus settings werden nur mit einer Konsolen-Login-Sitzung und einem Personal Access Token aufgerufen. Ein Space Access Token, ein Delivery Access Token oder ein ServiceUser-Token kann die APIs dieser Liste nicht aufrufen, gleichgültig welche Aktionen in der Rolle eingetragen sind.

Die Aktionsliste der Berechtigungs-Maps (contentType, content, media, script), die Filterschlüssel (self, contentType, createdBy, tag), die Bedeutung von :self und die Frage, welcher Filter in welcher Map gültig ist, richten sich nach dem obigen Abschnitt Berechtigungs-Maps: contentType, content, media.

script (Script-Berechtigungen)

script ist die Berechtigungs-Map für Script (deklarative Backend-Endpunkte, die vom Frontend aufgerufen werden). Ihr Aufbau entspricht dem von content und media: Aktionen als Schlüssel und Allow/Deny-Regel-Arrays als Werte. Verwendet werden folgende Aktionen:

• Create, Read, Edit, Delete: Erstellen, Lesen, Bearbeiten und Löschen einer Script-Ressource.
• Execute: Ein Script ausführen (Aufruf von /execute). Diese Aktion ist spezifisch für Script.
• All: Die übergeordnete Aktion, die alle oben genannten umfasst.

Da ein Script keine Ressource ist, die veröffentlicht wird, werden Veröffentlichungsaktionen wie Publish/Unpublish nicht verwendet. Als Regelfilter lassen sich self und createdBy verwenden.

• self: Beschränkt auf genau ein bestimmtes Script. Hier wird ein Refer auf dieses Script eingetragen (targetType ist Script).
• createdBy: Beschränkt auf den Ersteller (mit :self auf "nur die selbst erstellten Script").

contentType und tag sind keine Achsen, die an einem Script hängen, daher wird das Speichern der Rolle bei ihrem Eintrag abgelehnt.

Um beispielsweise die Ausführung beliebiger Script zu erlauben, das Lesen jedoch auf die selbst erstellten zu beschränken:

"script": {
  "Execute": { "Allow": [] },
  "Read": {
    "Allow": [
      { "createdBy": { "sys": { "id": ":self", "type": "Refer", "targetType": "User" } } }
    ]
  }
}

Mit self eingeschränkt, ergibt sich die minimale Berechtigung, mit der sich nur ein einziges Script ausführen lässt. Wenn Sie einem externen System wie einem Zahlungsdienstleister Ausführungsrechte geben, ist das der Weg, nur die eine Anlaufstelle zu öffnen, die dieses System aufrufen wird, und alles Übrige geschlossen zu halten.

"script": {
  "Execute": {
    "Allow": [
      { "self": { "sys": { "id": "3trmXRMZcTAjDnphewjj1AaxYcaxlK", "type": "Refer", "targetType": "Script" } } }
    ]
  }
}

Binden Sie diese Rolle an ein Space Access Token, lässt sich mit diesem Token nur das angegebene Script ausführen. Warum man auf ein einzelnes Ausführungsrecht einschränkt und dass eine Script-Ausführung die Berechtigungen des Autors delegiert bekommt, wird unter Script-Ausführungssemantik, Einschränkungen und Sicherheit behandelt.

Diese script-Berechtigung legt fest, ob die Script-Ressource ausgeführt und verwaltet werden darf. Davon unabhängig gilt: Beim Verfassen eines Script (Erstellen oder Bearbeiten) muss der Autor zum Speicherzeitpunkt tatsächlich die Content-/Media-Aktionsberechtigungen besitzen, auf die sich die Statements des Script beziehen; andernfalls wird das Speichern abgelehnt (siehe Fehler bei Script). Näheres dazu unter Script-Ausführungssemantik, Einschränkungen und Sicherheit.

Fehler

Dies sind die Codes, die beim Umgang mit einer SpaceRole auftreten. Codes, die allen Ressourcen gemeinsam sind, finden Sie unter Gemeinsame Fehler.

API

Die Basis-URL aller folgenden Endpunkte ist https://cma.weegloo.com/v1, und im Header Authorization ist ein Bearer-Token erforderlich, das gegen CMA authentifiziert. Beim Ändern einer Rolle (PUT, PATCH) muss für die optimistische Nebenläufigkeitskontrolle zusätzlich der Header X-Weegloo-Version (die aktuelle sys.version der Ressource) gesendet werden. Beim Erstellen und Löschen entfällt dieser Header. Standardmäßig bereitgestellte Rollen mit sys.isLocked gleich true können nicht geändert oder gelöscht werden.

Verwandte Dokumente

• Space Membership: Bindet eine SpaceRole an die roles eines Mitglieds.
• Delivery Access Token: Auslieferungs-Token, das an eine least-privilege-SpaceRole gebunden wird.
• Content Type: Der Content Type, auf den die Berechtigungsregeln verweisen.