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
Right now we pass in the permissions object and getAuthLevel methods by assigning them directly into the schema object. If we add more options in the future, we'd probably add them in the same way. This means we're polluting that shared space with object keys, and these may potentially collide with other extensions/mongoose properties down the road.
A safer approach would be to have these options passed into the plugin installation:
mySchema.plugin(authz, {
permissions: {...},
getAuthLevel: function () {...},
});
This has a few advantages:
All the configuration information for authorization is in one place, easy to see.
It doesn't pollute a shared space, so we don't have to worry about conflicts of getting our information overwritten.
The challenge it presents are:
We have to do a little more work to pass around this options object internally in the library. We could stick it in mySchema.authorizationOptions to have a sort of middle ground. And that key could be changed int he future since it's an internal implementation detail.
The configuration object may look quite gnarly and seem harder to use.
Thoughts?
The text was updated successfully, but these errors were encountered:
Right now we pass in the
permissions
object andgetAuthLevel
methods by assigning them directly into the schema object. If we add more options in the future, we'd probably add them in the same way. This means we're polluting that shared space with object keys, and these may potentially collide with other extensions/mongoose properties down the road.mySchema.permissions = {...}
mySechma.getAuthLevel = functiion () {...}
A safer approach would be to have these options passed into the plugin installation:
This has a few advantages:
The challenge it presents are:
mySchema.authorizationOptions
to have a sort of middle ground. And that key could be changed int he future since it's an internal implementation detail.Thoughts?
The text was updated successfully, but these errors were encountered: