-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Ability to define a bulk ALLOW once a wildcard DENY is in place. #148
Comments
This is tricky. I think everyone would agree that we need to err on the side of:
instead of
What would really help us define this solution is an example library / framework / platform that has this feature. I think you are on the right track with weighting. Currently the order ACLs are defined do not matter. I'm leaning towards a simpler approach: for more dynamic access control, you get a really handy hook so that you can ALLOW or DENY with javascript logic. Off the top of my head it would look like this: Product.on('access', function(ctx) {
switch(ctx.type) {
case 'read':
ctx.allow();
break;
case 'write':
case 'delete':
if(ctx.is('admin', 'owner')) {
ctx.allow();
} else {
ctx.deny();
}
break;
default:
ctx.deny('you must be an admin or owner...');
break;
}
}); A global hook would make it easy to define logic across models: app.on('access', function(ctx) {
// also support async
setTimeout(function() {
if(ctx.model === 'SomeModel') {
ctx.allow();
} else {
ctx.deny();
}
});
}); /cc @raymondfeng @bajtos |
Unfortunately, I don't have a good example ACL system ... hmm. Having per-model and global hooks (I'd be more likely to use the global ones for what I'm doing) seems like it could be used to build what I'm looking for, but I'd have to handle role/acl configuration/definition in a custom manner... (Do able, just seems a bit unnecessary.) |
In addition to the proposal to have method/model/global level hooks (+1), maybe we can set up the 'global' ACLs on base |
As part of our issue triage process, I am closing items that have been inactive for an extended period of time. If anybody thinks the feature proposed here is still relevant and should be prioritised, then please leave a comment to let us know. |
The way permissions are presently defined, a wildcard
DENY
trumps any acl does not exactly match onmodel
,property
, andaccessType
. While this is the technically correct solution, it would be nice to be able to setup a wildcardDENY
for$everyone
and then do a wildcardALLOW
for other roles.I know this presents a problem with deciding which acl should have priority as there is currently nothing to assign a weight to roles or the acls themselves. Adding that should make this pretty simple to do.
The text was updated successfully, but these errors were encountered: