You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the example above we extended the **userSchema** by adding a *permissions* object. This will not persist to your documents.
91
69
92
-
The permissions object consists or properties that represent your authorization levels (or groups). For each group, there are 4 permissions you can configure.
93
-
*`save` (create) - Boolean
70
+
The permissions object consists of properties that represent your authorization levels (or groups). For each group, there are 4 permissions you can configure.
71
+
* `create` - Boolean
94
72
* `remove` - Boolean
95
-
*`write` - [array of fields]*NOTE: if `upsert: true`, the group will need to have `save` permissions too*
96
-
*`read`(find) - [array of fields]
73
+
* `write` - [array of fields] *NOTE: if `upsert: true`, the group will need to have `create` permissions too*
74
+
* `read` - [array of fields]
97
75
98
76
You can also specify a `defaults` group, which represents permissions that are available to all groups.
99
77
100
-
#### Example Uses
78
+
If you need the document in order to determine the correct authorization level for an action, you can place a static `getAuthLevel` function directly in your schema. For applicable actions, this function will be called with a specific document and a payload of data specified in the query. This is useful when the authorization level depends on matching properties of a user with properties of a specific document to determine if *that* user can modify *that* document.
101
79
102
-
###### *NOTE: If you do not add the authLevel option to your request, the plugin will not attempt to authorize it. This makes it possible for you to handle requests that may not be initiated by a user (eg. system call, batch job, etc.)*
80
+
###### *NOTE: The `getAuthLevel` approach does not work for update or remove queries since the document is not loaded into memory.*
103
81
104
-
***example update***
82
+
```javascript
83
+
var mongoose = require('mongoose');
105
84
106
-
You can also specify an array of authentication levels. This would merge the settings of each auth level.
###### *NOTE: the return document will be sanitized based on the group's permissions for `read`*
139
+
You can also have the permissions for a specific document injected into the document when returned from a find query using the `permissions` option on the query. The permissions will be inserted into the object using the key `permissions` unless you specify the desired key name as the permissions option.
const user = await User.find().setOptions({ authLevel: 'admin': permissions: true }).exec();
143
+
144
+
console.log(user.permissions);
145
+
// Outputs:
146
+
// {
147
+
// read: [...],
148
+
// write: [...],
149
+
// remove: [boolean]
150
+
// }
151
+
152
+
// OR
153
+
const user = await User.find().setOptions({ authLevel: 'admin': permissions: 'foo' }).exec();
154
+
155
+
console.log(user.foo);
156
+
// Outputs:
157
+
// {
158
+
// read: [...],
159
+
// write: [...],
160
+
// remove: [boolean]
161
+
// }
133
162
```
134
163
164
+
#### Example Uses
135
165
136
-
***example find***
166
+
###### NOTE: If no authLevel is able to be determined, permission to perform the action will be denied. If you would like to circumvent authorization, pass `false` as the authLevel (e.g. `myModel.find().setAuhtLevel(false).exec();`, which will disable authorization for that specific query).
167
+
168
+
***example update***
169
+
170
+
You can also specify an array of authentication levels. This would merge the settings of each auth level.
0 commit comments