-
Notifications
You must be signed in to change notification settings - Fork 150
[review] Security Guide #2321
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.
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
[review] Security Guide #2321
Changes from 9 commits
0440376
af9c5d8
b4aa6e8
83ce6d5
f11482f
7973567
abcf040
44a9aa4
68a8382
730c8d2
766a6cb
8034555
8c61d06
d357b84
95a50af
93f48d1
4ea3476
ba8869d
147d662
f9ea6a2
054112e
ba311b2
9f83cc7
b12db4a
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change | ||||
|---|---|---|---|---|---|---|
|
|
@@ -105,12 +105,12 @@ context db { | |||||
| ... | ||||||
| } | ||||||
|
|
||||||
| entity Issues : cuid { // implicitly auto-exposed (by composition) | ||||||
| entity Issues : cuid { // implicitly auto-exposed (by composition in Components) | ||||||
| category: Association to Categories; | ||||||
| ... | ||||||
| } | ||||||
|
|
||||||
| entity Components : cuid { // explicitly exposed (by projection) | ||||||
| entity Components : cuid { // explicitly exposed (by projection in IssuesService) | ||||||
| issues: Composition of many Issues; | ||||||
| ... | ||||||
| } | ||||||
|
|
@@ -262,21 +262,35 @@ Restrictions can be defined on different types of CDS resources, but there are s | |||||
| | entity | <Y/> | <Y/> | <Y/><sup>1</sup> | | | ||||||
| | action/function | <Na/> | <Y/> | <Na/><sup>2</sup> | = `@requires` | | ||||||
|
|
||||||
| > <sup>1</sup>For bound actions and functions that are not 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>1</sup>For bound actions and functions that are not bound against a collection, Node.js supports instance-based authorization at the entity level, see [link] (somewhere in Node.js docs)<br> | ||||||
|
renejeglinsky marked this conversation as resolved.
Outdated
|
||||||
| > <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`. | ||||||
|
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Should it say "bound and unbound actions and functions"? In consequence we should add
Suggested change
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @BraunMatthias What do you think? |
||||||
|
|
||||||
| 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 | ||||||
| ::: code-group | ||||||
|
renejeglinsky marked this conversation as resolved.
Outdated
|
||||||
| ```cds [Model w/ unsupported privilege properties] | ||||||
| service CatalogService { | ||||||
| entity Products as projection on db.Products { ... } | ||||||
| actions { | ||||||
| @(requires: 'Admin') | ||||||
| action addRating (stars: Integer); | ||||||
| } | ||||||
| function getViewsCount @(restrict: [{ to: 'Admin' }]) () returns Integer; | ||||||
| function getViewsCount @(restrict: [{ grant: 'READ' to: 'Admin' }]) () returns Integer; | ||||||
|
renejeglinsky marked this conversation as resolved.
Outdated
|
||||||
| } | ||||||
| ``` | ||||||
| ```cds [Resulting model] | ||||||
| service CatalogService { | ||||||
| entity Products as projection on db.Products { ... } | ||||||
| actions { | ||||||
| @(requires: 'Admin') // is already in implicit {grant: '*'} | ||||||
| action addRating (stars: Integer); | ||||||
| } | ||||||
| //unsupported property is removed, means implicit { grant: '*'} | ||||||
| function getViewsCount @(restrict: [{ to: 'Admin' }]) () returns Integer; | ||||||
| } | ||||||
|
renejeglinsky marked this conversation as resolved.
Outdated
|
||||||
|
|
||||||
| ``` | ||||||
| ::: | ||||||
|
renejeglinsky marked this conversation as resolved.
Outdated
|
||||||
|
|
||||||
|
|
||||||
| ### Combined Restrictions { #combined-restrictions} | ||||||
|
|
@@ -413,7 +427,25 @@ The [restrict annotation](#restrict-annotation) for an entity allows you to enfo | |||||
| In addition, you can define a `where`-condition that further limits the set of accessible instances. | ||||||
| This condition, which acts like a filter, establishes *instance-based authorization*. | ||||||
|
|
||||||
| ### Filter Conditions { #filter-consitions } | ||||||
| ### Filter Conditions | ||||||
|
|
||||||
| For instance, a user is allowed to read or edit `Orders` (defined with the `managed` aspect) that they have created: | ||||||
|
renejeglinsky marked this conversation as resolved.
|
||||||
|
|
||||||
| ```cds | ||||||
| annotate Orders with @(restrict: [ | ||||||
| { grant: ['READ', 'UPDATE', 'DELETE'], where: (CreatedBy = $user) } ]); | ||||||
| ``` | ||||||
|
|
||||||
| Or a `Vendor` can only edit articles on stock (that means `Articles.stock` positive): | ||||||
|
|
||||||
| ```cds | ||||||
| annotate Articles with @(restrict: [ | ||||||
| { grant: ['UPDATE'], to: 'Vendor', where: (stock > 0) } ]); | ||||||
| ``` | ||||||
|
|
||||||
| ::: tip | ||||||
| Filter conditions declared as **compiler expressions** ensure validity at compile time and therefore strengthen security. | ||||||
| ::: | ||||||
|
|
||||||
| The condition defined in the `where` clause typically associates domain data with static [user claims](cap-users#claims). | ||||||
| Basically, it *either filters the result set in queries or accepts only write operations on instances that meet the condition*. | ||||||
|
|
@@ -444,24 +476,6 @@ You can define filter conditions in the `where`-clause of restrictions based on | |||||
| </div> | ||||||
|
|
||||||
|
|
||||||
| For instance, a user is allowed to read or edit `Orders` (defined with the `managed` aspect) that they have created: | ||||||
|
|
||||||
| ```cds | ||||||
| annotate Orders with @(restrict: [ | ||||||
| { grant: ['READ', 'UPDATE', 'DELETE'], where: (CreatedBy = $user) } ]); | ||||||
| ``` | ||||||
|
|
||||||
| Or a `Vendor` can only edit articles on stock (that means `Articles.stock` positive): | ||||||
|
|
||||||
| ```cds | ||||||
| annotate Articles with @(restrict: [ | ||||||
| { grant: ['UPDATE'], to: 'Vendor', where: (stock > 0) } ]); | ||||||
| ``` | ||||||
|
|
||||||
| ::: tip | ||||||
| Filter conditions declared as **compiler expressions** ensure validity at compile time and therefore strengthen security. | ||||||
| ::: | ||||||
|
|
||||||
| At runtime you'll find filter predicates attached to the appropriate CQN queries matching the instance-based condition. | ||||||
|
|
||||||
| :::warning Modification of Statements | ||||||
|
|
||||||

Uh oh!
There was an error while loading. Please reload this page.