Hi, I'm trying to implement simple ACL using database into Auth.
I've got two db tables:
`roles` - Holds roles for given namespace, modules (namespaces) can specify own roles:
id<int>, namespace<string>, name<string>
`access` - Holds users' access information for given resource:
id<int>, resource<string>, roles<string>
where resource is a string in format: {NAMESPACE}::{CLASS}@{METHOD}
and roles is array of roles
Finally, here is has_access method: http://pastebin.com/zSzYRTFs
Can you give me your thoughts about this solution? I'm afraid about database speed because of many strings.
On the other hand, this will be used and defined only for users with access to site backend (around 10).
This is not to be extra configurable and complex but simple and useful.
I don't think it's going to be too much of a performance hit. And if that is the case, you can always consider caching the data (in Memcached for example).
It would be cool if you can implement this as a package that extends Auth. Don't forget to include some documentation and the migration files to create the tables.
Are you maintaining the "one user -> one group -> multiple roles" principe of the default Auth driver, or are you going for multiple groups per user as well?
Also, it would be great if you could make this backward compatible, so that people that already use Auth can slot your package in, and nothing would break.
I can see a lot of people wanting to use a package like this. We can host it on http://github.com/fuel-packages when it's finished, and give you rights on the repo so you can update it yourself.
You're right, additional cache mechanism will be just fine in almost every situation.
Package extending package? Sounds uncommonly ^^ This will require additional work but I'll see what I can do. I guess in this case I can't use ORM anymore.
For my own needs I was only thinking about the simplest "one user -> multiple roles" however public package should be quite more complex so I can try to implement multiple groups per user where roles might be assigned to group or directly to the user.
Another implication would be that user's roles are more important than user's group roles and adding "negative" (no access) roles to users directly. But this is only idea.
@EDIT
And one technical question. Is such thing ACL or RBAC?
@EDIT2
Ok, I worked out elegant Auth package extending. Now all you need to do is load my package (lets say "DbAcl" ) and Auth will be loaded automatically if is't not loaded yet.
Auth package will keep all its functionality, all user info that DbAcl requires is user ID.
Usage it's just DbAcl::has_access($class, $method, $role);
Classes in a package are classes, just like any other. They are in a namespace, and they can extend other classes. So it's not a problem that one package extends another.
The only complication you might run into is that Auth's namespace is added to the Core (and thus aliased to global), which might make extension a bit more complicated.
ACL is the (list of) rule(s) that allow or deny access. RBAC is the mechanism in which you give access based on roles. As such you also have TBAC (based on tasks), and RTBAC, which is a combination of the two.
One user -> multiple roles is standard functionality of the current Auth package.
I've created github repo so you can check out the code: http://github.com/OscaTutenchamon/DbAcl
If this code is worth something you can create repo at fuel-packages so I'll move it there.
Donate
