Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[wip] security guide fixes #1511

Draft
wants to merge 2 commits into
base: main
Choose a base branch
from
Draft

[wip] security guide fixes #1511

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
f038c23
Vendor -> Customer
sjvans Dec 11, 2024
bc1f37c
comments
sjvans Dec 11, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
7 changes: 6 additions & 1 deletion guides/security/authorization.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -344,8 +344,13 @@ Restrictions can be defined on different types of CDS resources, but there are s
| action/function | <Na/> | <Y/> | <Na/><sup>2</sup> | = `@requires` |

> <sup>1</sup>For bound actions and functions that aren't bound against a collection, Node.js supports instance-based authorization at the entity level. For example, you can use `where` clauses that *contain references to the model*, such as `where: CreatedBy = $user`. For all bound actions and functions, Node.js supports simple static expressions at the entity level that *don't have any reference to the model*, such as `where: $user.level = 2`.

> <sup>2</sup> For unbound actions and functions, Node.js supports simple static expressions that *don't have any reference to the model*, such as `where: $user.level = 2`.

// I'm a bit confused by 1. maybe the table needs to distinguish between bound and unbound operations?

// I'd like to get rid of the support for "simple static expressions" in cds^9!!!

Unsupported privilege properties are ignored by the runtime. Especially, for bound or unbound actions, the `grant` property is implicitly removed (assuming `grant: '*'` instead). The same also holds for functions:

```cds
Expand Down Expand Up @@ -395,7 +400,7 @@ The resulting authorizations are illustrated in the following access matrix:
| `CustomerService.Orders` (*) | <X/> | <Y/><sup>1</sup> | <X/> | <X/> |
| `CustomerService.monthlyBalance` | <Y/> | <X/> | <X/> | <X/> |

> <sup>1</sup> A `Vendor` user can only access the instances that they created. <br>
> <sup>1</sup> A `Customer` user can only access the instances that they created. <br>

The example models access rules for different roles in the same service. In general, this is _not recommended_ due to the high complexity. See [best practices](#dedicated-services) for information about how to avoid this.

Expand Down
Loading