What about true resource check (maybe with groups) about accesscontrol HOT 3 CLOSED

Hey @onury thanks for replying.

Or are you talking about grouping unrelated resources such as group1 would include resources video and photo for example?

Yeah more like this. Like an arbitrary group, defined by an id, grouping some videos, photos, etc.

ac.grant('admin')
.readAny('videoGroup1')
.readAny('videoGroup2')
// so on ...

I think it could work but it would be strange to mix a resourceType concept with a resourceInstance concept, wouldn't it ?

EDIT: and it would be a pain to, for example, grab "all granted videos", or even "all granted video groups".

For you to understand, we defined the following concept, to have the more flexible possible ACL system :

• A user can have many roles [id, roles]
• A role is like [id, name]
• A group is like [id, name]
• A resource (this is not a table, each table under ACL control is a resource) has many groups [id, groups]
• A permission grants operations to a role to a resourceType within many groups [id, role, groups, resourceType, operations]
  (- An operation is C/R/U/D)

This may not be a perfect design, but this is flexible.

from accesscontrol.

I need to understand what you gain by grouping resources, in your case.

What you call "a group of a resource" or a "resource type" is essentially just another resource, if it needs to be distinguished from others.

You're defining a video resource and a group of video items (records) as group1. Wouldn't it work if instead you define simpler and more specific resources such as:

ac.grant('admin')
    .readAny('videoGroup1')
    .readAny('videoGroup2')
    // so on ...

Or are you talking about grouping unrelated resources such as group1 would include resources video and photo for example?

from accesscontrol.

Well, actually grouping should mean aliasing multiple resources with another name. Specifically, group1 would consist of the video and photo resources. Not a sub-list of video/photo resource instances. Otherwise, it's against the concept this library implements.

AccessControl has no knowledge about individual instances or users; it implements RBAC with implicit access control. An implicit access control only works with your (the developer's) code and decisions.

When you bring instance to this concept, it's not really meaningful. An instance is dynamic (it may exist, then it may not). But a resource is a definition; it's always there, static. For example, even if you have no videos (instances) yet, you can have a logical video resource that has all the semantics to manage/restrict the resource.

Same for users vs roles. Don't confuse RBAC for applications with SQL implementations of ACL or file-system ACL. You should never involve individual users/objects in this.

Think of it this way; if we were to authorize access to a resource by individual users; then we'd have to update the code every time a new user is added or deleted; or grants are changed for that user. In other words, you shouldn't need to touch the source code when policies/privileges change.

In v3, I'll introduce scopes which will bring finer granularity. You will be able to switch between remaining implicit (as is) or a bit more explicit.

I cannot give you a code example since the API is not finalized yet but for example, scopes will allow you to restrict access based on date and time. Or it will allow you to add tags to a grant. These tags would be only meaningful to you/your application. For example a DELETE action will mean a permanent delete app-wise but if a grant is tagged with soft it would mean an UPDATE.

Maybe you can take advantage of scopes for your use case. You'd have a better understanding once v3 is released. For now, I'll leave it at this..

from accesscontrol.