What this is about
What should happen when a request asks for something that is not allowed? There are two answers:
- Strict: CDMS rejects the request with an error that says exactly what is missing.
- Lenient: CDMS leaves out what is not allowed and returns the rest. Where that is not possible, a more general error comes back.
Which answer applies is set by strict mode. It is on by default.
Where it is set
Strict mode applies to a whole CDMS instance: to all models and all requests. You set it with the environment variable STRICT_MODE. If it is missing, true applies.
A client cannot switch it, and a single model cannot be set differently.
The matrix
| Case | Strict mode on | Strict mode off |
|---|---|---|
read by id, read role missing | 403 missing-permission|<read role> | 404 not-found |
| search, read role missing | 403 missing-permission|<read role> | 403 empty-request-left |
single reference in the response, role missing | 403 missing-permission|<role> | field is null, no error |
list in the response, role missing | 403 missing-permission|<role> | 403 empty-request-left for the whole request |
| create, role missing | 403 missing-permission|<role> | 403 missing-create-role |
| change (PUT, PATCH), role missing | 403 missing-permission|<role> | 403 missing-update-role |
| delete, role missing, also in the cascade | 403 missing-permission|<role> | 403 missing-delete-role |
| read history, role missing | 403 missing-permission|<role> | 403 missing-read-role / missing-history-role |
| rollback, role missing | 403 missing-permission|<role> | 403 missing-rollback-role |
| create or change a child along, role and field role missing | 403 missing-permission|<field role or role> | 403 missing-create-role / missing-update-role |
| new child in a list, relation without CREATE | 400 recursive-create-not-allowed|<field> | entry is skipped |
| new child as single reference, relation without CREATE | 400 recursive-create-not-allowed|<field> | the field becomes empty |
The last two rows are not about a role but about the flags of the relation. See The four cases in nested writing.
Strict and lenient compared
Strict mode on
default
- every missing role → 403
- the key names the missing role
- the client knows right away which role it needs
- same request, same result for every person
Strict mode off
lenient
- single references without the role become
null - read by
idwithout the role → 404 - writing → 403 without the role name
- an answer with
nulllooks like an empty field
Reading in detail
| Strict mode | role employee | role company | Answer |
|---|---|---|---|
| on | no | – | 403 missing-permission|<role of employee> |
| on | yes | no | 403 missing-permission|<role of company> |
| off | no | – | 404 not-found |
| off | yes | no | 200, company is null |
| – | yes | yes | 200 with company |
Why strict is the default
- Errors show up. A missing role shows up in the first test, not only when a person wonders about empty fields.
nullstays unambiguous. With strict mode,nullin an answer means: not set or invisible. Without it, it can also mean: role missing.- The key helps.
missing-permission|audit-question-readtells you exactly which role you have to grant.
The filters of the row level do not depend on strict mode. Invisible rows always return 404 or are missing from the list. See Why invisible objects return 404.
Pitfalls
Where to go next
- Which role each operation requires: Model roles
- Permissions through a relation: Permissions on relations (field roles)