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.
mySchema.permissions = {...}
mySechma.getAuthLevel = functiion () {...}
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?
Right now we pass in the
permissionsobject andgetAuthLevelmethods 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.authorizationOptionsto have a sort of middle ground. And that key could be changed int he future since it's an internal implementation detail.Thoughts?