docs(auth): Mention 403 pitfall + Java specifics #1463
Conversation
| TODO: But in Java, it also works for custom events? And in Node as well, right? | ||
|
|
||
| > <sup>1</sup> Node.js supports _static expressions_ that *don't have any reference to the model* such as `where: $user.level = 2` for all events. | ||
| > <sup>2</sup> CAP Java uses a filter condition by default. |
There was a problem hiding this comment.
whether the filter applies as result filter or reject condition now depends on the the query (selection or not). I think we should mention this explicitly.
There was a problem hiding this comment.
You refer to my TODO for custom events?
Something like:
- custom event (as reject condition if it selects an entity)
It seems that Node.js assumes that bound actins/functions trigger read events (SELECTs), but I could be mistaken.
There was a problem hiding this comment.
Comment was:
TODO: But in Java, it also works for custom events? And in Node as well, right?
guides/security/authorization.md
Outdated
| @@ -518,6 +521,16 @@ Supported features are: | |||
| * [Exists predicate](#exists-predicate) based on subselects. | |||
|
|
|||
|
|
|||
| <div class="impl java"> | |||
|
|
|||
| CAP Java 3.5.0 introduced an option to enable rejection conditions for `UPDATE`, `DELETE` and custom events. Enable it via <Config java keyOnly>cds.security.authorization.instance-based.reject-selected-unauthorized-entity.enabled: true</Config> | |||
There was a problem hiding this comment.
the reject condition also works with READ, doesn't it?
There was a problem hiding this comment.
The reject condition is only implemented for write-events (+ custom events). For read events, it remains 404, i.e. filtering.
Co-authored-by: BraunMatthias <[email protected]>
Co-authored-by: BraunMatthias <[email protected]>
Co-authored-by: BraunMatthias <[email protected]>
| TODO: But in Java, it also works for custom events? And in Node as well, right? | ||
|
|
||
| > <sup>1</sup> Node.js supports _static expressions_ that *don't have any reference to the model* such as `where: $user.level = 2` for all events. | ||
| > <sup>2</sup> CAP Java uses a filter condition by default. |
There was a problem hiding this comment.
Comment was:
TODO: But in Java, it also works for custom events? And in Node as well, right?
No description provided.