Sicherheit von Daten

Modell (darf ich diese Operation?), Beziehung (darf ich über dieses Feld?) und Zeile (darf ich dieses Objekt?). Wie die Ebenen hintereinander greifen.

Welche Rolle eine Operation verlangt: Basisrolle, Rolle je Aktion, Endpunkt-Rolle, öffentlicher Zugriff. PATCH nutzt die Update-Rolle.

Aus dem API-Pfad /audit/question wird audit-question, daraus audit-question-read. Die Regel an Beispielen.

Eine Feldrolle an einer Beziehung erlaubt, ein Kindmodell über genau ein Feld zu lesen oder zu schreiben, ohne direkten Zugang zum Kindmodell. An einfachen Feldern wirkt eine Rolle anders: als zusätzliche Bedingung.

Eine Rolle an einem einfachen Feld schützt einen einzelnen Wert. Wer sie nicht hat, sieht das Feld nicht, kann es nicht ändern und nicht danach suchen. Das Modell selbst bleibt lesbar.

Ein Textfeld mit der Regel „verschlüsselt“ steht verschlüsselt in der Datenbank und kommt entschlüsselt zurück. Was du dafür einstellst, wie ein Schlüsselwechsel geht und was mit dem Feld nicht geht.

Bei Benutzer-Modellen sieht jede Person nur ihre eigenen Zeilen. Wie _userId gesetzt und geprüft wird.

Ein Attribut der Person (z. B. projects) schränkt ein Datenfeld ein. Wie EQ/IN entsteht, was * bedeutet, was bei fehlendem Attribut passiert und was für Personen mit mehreren Mandanten gilt.

Wie ein Projekt eigene Sichtbarkeitsregeln einbaut und warum ein Pflichtfilter, der nicht aufgelöst werden kann, die Anfrage abbricht statt still zu verschwinden.

Ein Objekt, das man nicht sehen darf, gibt es aus Sicht des Aufrufers nicht. Das gilt auch beim Ändern und Löschen: Man kann nur schreiben, was man lesen kann.

Ob eine unzulässige Anfrage einen Fehler liefert oder still gekürzt wird. Wo das wirkt und warum strikt der Standard ist.

Was eine Anfrage ohne Token erreicht: offene Pfade, Endpunkte ohne Rolle, und wie ein ungültiges Token behandelt wird.