conversely / backend

alllll the backend stuff
MIT License
0 stars 1 forks source link

Access Control Tables #26

Open ghost opened 10 years ago

ghost commented 10 years ago

Access Control is not fun.

Role Table: id, label, description, createtime Permissions: id, label, description, reference, createtime

label and description are the human readable stuff. reference for permission is where the tie to the code happens.

Role_Permission Table: id, role(role.id), permission(permission.id) GrantOrDeny, grantedBy(user.id), createTime

Okay: I don't know what the plan is for access control--or even if there is one, so this is all conjecture at best. :D the User object can have an array of permissions, where permissions[reference] = 0 or 1, granting or denying the user object permission to access those object. then whenever an object is access controlled, just check that the user has the permission and that the value is true. Anyway, that's one way.

I like grantOrDeny because it allows explicit grant and explicit deny.

Drupal just has one table: Role and Role_Permission, and it stores all the variables in one big blob. I don't like this way, but just putting it out there.