Worum es geht
Stell dir einen Tresor vault mit Notizen note vor. Eine Person soll die Notizen eines Tresors sehen, wenn sie den Tresor liest. Sie soll aber nicht über /note/query alle Notizen durchsuchen können.
Mit Modellrollen allein geht das nicht: Die Leserolle von note öffnet immer auch den eigenen Endpunkt von note. Dafür gibt es Feldrollen. Eine Feldrolle hängt an einer Beziehung, hier am Feld vault.notes, und heißt z. B. vault-notes-read.
Zwei Wege zum selben Kind
flowchart LR
P(["Person mit vault-read<br/>und vault-notes-read"])
P -->|"POST /vault/read/{id}<br/>response: notes"| V["vault"]
V -->|"über das Feld notes:<br/>vault-notes-read genügt"| N["note"]
P -.->|"POST /note/query<br/>verlangt note-read"| X["403"]
| Weg | Was CDMS prüft | Ergebnis mit vault-read und vault-notes-read |
|---|---|---|
über den Tresor: POST /vault/read/{id} mit notes in der response | Rolle von vault, dann Feldrolle oder Leserolle von note | 200 mit Notizen |
direkt: POST /note/query | Leserolle von note | 403 `missing-permission |
Wann die Feldrolle zählt
Steigt eine Anfrage über eine Beziehung in ein anderes Modell hinab, prüft CDMS zwei Dinge. Eines davon genügt:
| Feldrolle an vault.notes für diese Operation | Rolle von note für diese Operation | Ergebnis |
|---|---|---|
| ja | – | erlaubt über das Feld |
| nein | ja | erlaubt über die Rolle des Kindmodells |
| nein | nein | 403 missing-permission|vault-notes-<operation> |
| am Feld keine Feldrolle festgelegt | nein | 403 missing-permission|<rolle von note> |
Die Operation muss genau passen:
| Operation am Kind | Feldrolle |
|---|---|
lesen, auch Listen in der response | …-read |
| mitanlegen | …-create |
| mitändern, per PUT oder PATCH | …-update |
| mitlöschen in einer Kaskade | …-delete |
Varianten
Wann: response nennt notes
-
1CDMSprüft die Leserolle von
vaultund liest den Tresor -
2CDMS
vault-notes-readvorhanden → liest die Notizen ohnenote-read -
3CDMS→Databaseliest nur Notizen, die die Filter von
notedurchlassen
Ergebnis: Die Filter der Zeilen-Ebene gelten weiter. Eine Feldrolle macht keine unsichtbare Notiz sichtbar.
Wann: POST /vault/create mit neuen Notizen in notes
-
1CDMSprüft die Anlegerolle von
vault -
2CDMS
vault-notes-createvorhanden → legt die Notizen ohnenote-createan -
3CDMSliest das Ergebnis zurück. Nennt die
responsedie Notizen, gilt wie beim Lesenvault-notes-readodernote-read
Ergebnis: Wer nur vault-notes-create hat, lässt die Notizen aus der response weg, sonst scheitert das Zurücklesen. Siehe Anlegen und Zurücklesen: STRICT oder LENIENT.
Wann: DELETE /vault/delete/{id}, notes mit DELETE-Flag
-
1CDMSprüft die Löschrolle von
vault -
2CDMS
vault-notes-deletevorhanden → löscht die Notizen ohnenote-delete -
3CDMShat eine Notiz selbst abhängige Kinder, braucht jedes davon wieder seine eigene Rolle oder eine Feldrolle an der Beziehung der Notiz
Ergebnis: Siehe Abhängige Objekte (Kaskaden).
Wie weit eine Feldrolle reicht
- Nur eine Stufe.
vault-notes-readgilt für die Notizen, nicht für das, was an einer Notiz hängt. Für die nächste Stufe brauchst du wieder die Rolle des Modells oder eine Feldrolle an der Beziehung der Notiz. - Nur diese Operation.
vault-notes-readerlaubt kein Mitändern. Dafür brauchst duvault-notes-updateodernote-update. - An einfachen Feldern anders. Eine Rolle an einem einfachen Feld wie
note.textöffnet keinen Weg, sie schützt den Wert zusätzlich zur Rolle des Modells. Siehe Geschützte Werte. - Nie der direkte Weg. Auch mit allen vier
vault-notes-…-Rollen liefert jeder Endpunkt unter/note/…403 mit der Rolle vonnote.
Wo du Feldrollen festlegst
Im Hub markierst du an der Beziehung die Operationen, für die es eine Feldrolle geben soll. Den Namen bildet der Generator: Basisrolle des Modells, Feldname, Operation. Siehe Wie Rollennamen entstehen.
Fallen
Wie es weitergeht
- Die Rollen des Modells selbst: Modellrollen
- Rollen an einfachen Feldern: Geschützte Werte
- Die Ebenen im Zusammenhang: Die drei Ebenen im Überblick
- Wie Beziehungen geschrieben werden: Die vier Fälle beim verschachtelten Schreiben