Worum es geht
Ein Objekt ist für dich unsichtbar, wenn einer der Filter der Zeilen-Ebene es ausschließt: Es gehört einer anderen Person (eigene Daten), es passt nicht zu deinem Profil (Attributfilter) oder ein eigener Filter des Projekts lässt es nicht durch.
Für ein unsichtbares Objekt antwortet CDMS genauso wie für ein Objekt, das es gar nicht gibt: 404.
Warum nicht 403?
- sagt: es gibt das Objekt
- ein Angreifer könnte fremde
ids durchprobieren und lernen, welche existieren - CDMS nutzt 403 für fehlende Rollen: die gelten für alle Objekte gleich und verraten nichts über ein einzelnes
- sagt nichts darüber, ob das Objekt existiert
- ein fremdes Objekt und eine erfundene
idsehen gleich aus - CDMS nutzt 404 für unsichtbare Zeilen
Varianten
Wann: POST /read/{id}
-
1CDMSprüft die Leserolle
-
2CDMS→Databaseliest die Zeile mit
idund allen Filtern -
3CDMSkeine Zeile → 404
not-found
Ergebnis: Beim Lesen kommt die Rolle zuerst: Ohne Leserolle bekommst du 403, auch für ein unsichtbares Objekt.
Wann: POST /query
Unsichtbare Zeilen fehlen in data und zählen nicht in totalCount. Es gibt keinen Fehler.
Ergebnis: Die Trefferzahl verrät nie, wie viele Objekte es insgesamt gibt.
Wann: Referenz oder Liste, die du mitliest
Eine unsichtbare Einzelreferenz kommt als null. In einer Liste fehlen unsichtbare Einträge.
Ergebnis: null kann also heißen: nicht gesetzt oder für dich unsichtbar.
Wann: PUT /update/{id}, PATCH /update/{id}
-
1CDMS→Databasezählt die Zeile mit
idund denselben Filtern wie beim Lesen -
2CDMS0 → 404
not-found|<Dto>|<id> -
3CDMS1 → prüft jetzt erst die Änderungsrolle
Ergebnis: Beim Schreiben kommt die Sichtbarkeit zuerst: unsichtbar ergibt 404, auch ohne Rolle.
Wann: Ein Kind mit id in einem verschachtelten Schreibvorgang
Dieselben Filter wie beim Lesen, angewandt auf das Ziel: Ist es für dich unsichtbar, kommt 404 missing-object|<id>|<Modell> – dieselbe Antwort wie für eine id, die es nie gab. Dazu braucht es die Leseberechtigung des Zielmodells.
Ergebnis: Verbinden kannst du dich nur mit dem, was du auch ansehen dürftest. Siehe Die vier Fälle.
Wann: DELETE /delete/{id}
Wie beim Ändern: erst Sichtbarkeit (404), dann Löschrolle (403). Eine Leserolle brauchst du nicht, die Filter des Lesens gelten trotzdem.
Ergebnis: Siehe Der Ablauf eines DELETE.
Wann: POST /{id}/rollback/{revision}
Wie beim Ändern: erst Sichtbarkeit (404), dann Rollback-Rolle (403). Ein gelöschtes Objekt gibt es nicht mehr, auch dafür kommt 404. Hängt der Rollback eine Einzelreferenz um, gilt für altes und neues Ziel dasselbe wie beim Verknüpfen.
Ergebnis: Zurücksetzen kannst du nur, was du jetzt sehen kannst.
Wann: GET /{id}/file
Der Download liest das Objekt zuerst wie ein read. Unsichtbar → 404, bevor eine Datei fließt.
Ergebnis: Siehe Herunterladen.
Wann: POST /{id}/history
Erst die beiden Rollen (403), dann die Sichtbarkeit: unsichtbar → 404 missing-object|<id>|<Modell>. Ist das Objekt gelöscht, zählt sein letzter Stand vor der Löschung. Bei einem Modell mit Filter ist eine unbekannte id von einer verborgenen nicht zu unterscheiden.
Ergebnis: Siehe Historie lesen.
Entscheidungstabelle
| Operation | Rolle vorhanden | Objekt sichtbar | Antwort |
|---|---|---|---|
| lesen | nein | – | 403 missing-permission|<leserolle> |
| lesen | ja | nein | 404 not-found |
| ändern, löschen, rollback | – | nein | 404 not-found|<Dto>|<id> |
| ändern, löschen, rollback | nein | ja | 403 missing-permission|<rolle> |
| jede | ja | ja | erlaubt |
Fallen
Wie es weitergeht
- Welche Filter es gibt: Die drei Ebenen im Überblick
- Was ohne Strict Mode anders ist: Strict Mode