Worum es geht
Drei Codes sehen sich ähnlich, verlangen vom Client aber ganz verschiedene Reaktionen:
- 401: Dein Token taugt nicht. Hol ein neues.
- 403: Du bist bekannt, aber das hier darfst du nicht. Oder du hast gar kein Token geschickt.
- 404: Das Objekt gibt es für dich nicht. Vielleicht existiert es, aber du darfst es nicht sehen.
Die drei im Vergleich
- kommt nur von der Filterkette
- Token abgelaufen, kaputt oder falsch signiert
- kein Körper, Header
WWW-Authenticate: Bearer error="invalid_token" - CDMS hat die Anfrage nie gesehen
- kein Token: Filterkette, Körper ohne
messageKey - Mandant abgelehnt: Filterkette,
errormitcias.authentication.… - Rolle fehlt: CDMS,
missing-permission|<rolle> - gilt für alle Objekte eines Modells gleich
- Objekt fehlt oder ist unsichtbar:
not-found…,missing-object|… - Singleton noch nicht angelegt:
no-data-exists|use-create - Pfad unbekannt: kein
messageKey - verrät nie, ob ein fremdes Objekt existiert
Der Entscheidungsweg
flowchart TB
S{"Status?"} -->|401| R["Token erneuern,<br/>Anfrage einmal wiederholen"]
R --> R2{"wieder 401?"}
R2 -->|ja| L["neu anmelden"]
S -->|403| K{"Körper?"}
K -->|"kein messageKey,<br/>kein error"| H["Header Authorization prüfen,<br/>anmelden"]
K -->|"error: cias.authentication.…"| M["Mandant prüfen:<br/>Organisation, Header tenant"]
K -->|"messageKey"| P["Rolle fehlt:<br/>Aktion ausblenden, Hinweis zeigen"]
S -->|404| N{"messageKey?"}
N -->|"nein"| U["Pfad falsch:<br/>Modellpfad und Endpunkt prüfen"]
N -->|"no-data-exists…"| C["Singleton anlegen"]
N -->|"not-found, missing-object"| G["wie gelöscht behandeln:<br/>aus der Liste nehmen, zurück"]
In welcher Reihenfolge CDMS prüft
Wenn beides zutrifft, also die Rolle fehlt und das Objekt unsichtbar ist: Welcher Code kommt dann? Das hängt von der Operation ab.
Wann: POST /read/{id}, GET /read/{id}
-
1CDMSprüft die Leserolle
-
2CDMSRolle fehlt → 403
missing-permission|<leserolle> -
3CDMS→Datenbankliest die Zeile mit allen Filtern, keine Zeile → 404
not-found
Ergebnis: Ohne Leserolle kommt 403, egal ob das Objekt existiert.
Wann: PUT, PATCH, DELETE, POST /{id}/rollback/{revision}
-
1CDMS→Datenbankzählt die Zeile mit denselben Filtern wie beim Lesen
-
2CDMSunsichtbar oder nicht vorhanden → 404
not-found|<Dto>|<id> -
3CDMSsichtbar, Rolle fehlt → 403
Ergebnis: Beim Schreiben kommt die Sichtbarkeit zuerst. So verrät auch ein fehlendes Recht nichts über fremde Objekte.
Wann: Die Installation läuft mit STRICT_MODE=false.
Beim Lesen per id ohne Leserolle kommt dann 404 not-found statt 403. Beim Schreiben bleibt es bei 403, nur mit einem anderen Schlüssel, etwa missing-update-role.
Ergebnis: Siehe Strict Mode.
Die ganze Tabelle je Operation steht unter Warum Unsichtbares 404 liefert.
Reaktion des Clients je Code
| Status | Körper | Reaktion |
|---|---|---|
| 401 | leer | Token erneuern, Anfrage einmal wiederholen. Scheitert das Erneuern oder kommt wieder 401: neu anmelden. |
| 403 | leer oder ohne messageKey | Die Anfrage hatte kein Token. Header Authorization: Bearer <token> prüfen, sonst anmelden. |
| 403 | error mit cias.authentication.… (beim Download mit access_token im messageKey) | Mandant nicht bestimmbar, nicht bedient oder fehlt. Nicht wiederholen, Organisation oder Mandantenauswahl prüfen. |
| 403 | missing-permission|<rolle> u. a. | Rolle fehlt. Aktion ausblenden oder Hinweis zeigen. Nicht wiederholen. |
| 404 | not-found…, missing-object|… | Objekt ist weg oder unsichtbar. Aus der Anzeige nehmen, zur Liste zurück. Nicht wiederholen. |
| 404 | no-data-exists|use-create | Das Singleton gibt es noch nicht. Mit create anlegen. |
| 404 | ohne messageKey | Den Pfad gibt es nicht. Modellpfad und Endpunkt im Code prüfen. |
Fallen
Wie es weitergeht
- Alle Codes auf einen Blick: Landkarte der Statuscodes
- Wie der Fehlerkörper aufgebaut ist: Das Fehlerformat
- Welche Rolle eine Operation verlangt: Modellrollen
- Wie der Mandant bestimmt wird: Woher der Mandant einer Anfrage kommt
- Token erneuern: Token erneuern