Hi,
What is the best way to assign permissions to users?
a) Each user has a list of permissions associated with that user or
b) Each task/permission has a list of users that qualify or
c) Have a table with a row for each user/permission combination
Thanks!
John
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
This is where binary is actually helpful. You can store each
task/permission as a bit, ie, as a yes or no piece of data.
For example: read, write, edit, moderate ... a user with read/write
permissions only would be represented by: 1100, which in decimal is
12. So in effect, you're storing 4 values in one integer.
If you wanted to create a table to serve as a key to the permission
level codes, you could do that as well.
RO
On Wed, Aug 26, 2009 at 11:55 PM, John
> Hi,
>
>
>
> What is the best way to assign permissions to users?
>
>
>
> a) =A0 =A0 =A0Each user has a list of permissions associated with that us=
er or
>
> b) =A0 =A0 =A0Each task/permission has a list of users that qualify or
>
> c) =A0 =A0 =A0 Have a table with a row for each user/permission combinati=
on
>
>
>
> Thanks!
>
>
>
> John
>
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
On Aug 27, 2009, at 2:55 AM, "John"
> Hi,
>
>
>
> What is the best way to assign permissions to users?
>
>
>
> a) Each user has a list of permissions associated with that
> user or
Nope
>
> b) Each task/permission has a list of users that qualify or
Nope
>
> c) Have a table with a row for each user/permission combination
>
>
Sort of. Create two tables a login table with user details and a
specific field for a ROLE.
Then create a roles table that lists the various permissions. I store
this in binary form in one field ( 10001111100100 ) where one means
permission granted and 0 means not granted. I assign the permissions
thru a form with checkboxes. You could also have permissons assigned
to individual fields in the table ( ie fields for update, select, add,
delete etc) to make things easier.
This process is significantly simpler when managing users, it's easier
to adjust permissions on one role than to edit a bunch of users when
something changes.
>
> Thanks!
>
>
>
> John
>
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
Bastien
Sent from my iPod
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
John wrote:
> Hi,
>
>
>
> What is the best way to assign permissions to users?
>
>
>
> a) Each user has a list of permissions associated with that user or
>
> b) Each task/permission has a list of users that qualify or
>
> c) Have a table with a row for each user/permission combination
>
>
>
> Thanks!
>
>
>
> John
>
I'm not sure about "best", but I kind of like the way CakePHP does it:
http://book.cakephp.org/view/465/Understanding-How-ACL-Works
--
Thanks!
-Shawn
http://www.spidean.com
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
> Sort of. Create two tables a login table with user details and a specific
> field for a ROLE.
>
> Then create a roles table that lists the various permissions. I store this
[8<]
> This process is significantly simpler when managing users, it's easier to
> adjust permissions on one role than to edit a bunch of users when something
> changes.
In this mechanism, does a "role" differ significantly from a "group"?
I have to admin a CRM system that has both roles /and/ groups, and it
always seems a bit excessive. But maybe there's some benefit to roles,
as such, that I'm not seeing.
Thanks, Ben
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
On Aug 27, 2009, at 9:02 PM, Ben Dunlap
wrote:
>> Sort of. Create two tables a login table with user details and a
>> specific
>> field for a ROLE.
>>
>> Then create a roles table that lists the various permissions. I
>> store this
> [8<]
>> This process is significantly simpler when managing users, it's
>> easier to
>> adjust permissions on one role than to edit a bunch of users when
>> something
>> changes.
>
> In this mechanism, does a "role" differ significantly from a "group"?
> I have to admin a CRM system that has both roles /and/ groups, and it
> always seems a bit excessive. But maybe there's some benefit to roles,
> as such, that I'm not seeing.
>
> Thanks, Ben
Yes, they offer an additional layer of granularity on permissions. The
apps I write use groups and role to limit acces to certain
functionality. The roles determine functional access to records, ie
what the user can do with them. The groups membership determines what
records the user can see. E.g. If a user has membership in groups A
and B, they can see all records from created by or assigned to both
groups. A user who belongs to group B only, can only view the records
having group B membership.
Bastien
Sent from my iPod
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
>
> In this mechanism, does a "role" differ significantly from a "group"?
> I have to admin a CRM system that has both roles /and/ groups, and it
> always seems a bit excessive. But maybe there's some benefit to roles,
> as such, that I'm not seeing.
>
> Thanks, Ben
[JP]
As described, a "role" appears to act essentially the same as a "group" - a
predefined set of permissions that can be assigned to multiple users (as
opposed to a set of permissions unique to the user). Correct me if there's
a better way, but I think individual permissions can be set similarly -
except skip the role/group step and associate the binary permission string
directly with the user.
Thinking outloud:
In your case where you're dealing with both individual permissions as well
as groups, you could do both of the above, but have the individual
permissions override the group. You'd have to figure out a "third bit"
though, to act as a "no change" bit. Ie: 0 = deny, 1 = allow, 2 = NC. But,
that wouldn't allow you to convert and store the bit string in decimal.
So if group1 had a permission string of 1010, and user Joe was a member of
group1, but you wanted to take away the first bit's permission, and grant
the second bit, you could assign him the individual permission string of
0122 (deny, allow, NC, NC), resulting in his permissions being 0110.
You'd check it by checking the individual permissions first, and if the bit
(or digit in this case) were 2, then you would move on to checking the group
permissions.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
> As described, a "role" appears to act essentially the same as a "group"
> - a predefined set of permissions that can be assigned to multiple
> users (as opposed to a set of permissions unique to the user).
[JP]
I should say, the logic of a role is essentially the same as the logic
behind a group. It just adds, as Phpster said, another layer of control
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
> Yes, they offer an additional layer of granularity on permissions. The apps
> I write use groups and role to limit acces to certain functionality. The
> roles determine functional access to records, ie what the user can do with
> them. The groups membership determines what records the user can see. E.g.
But is this substantially different from just allowing "groups" to
determine access to functionality, /and/ access to records, and
letting the admin create different groups for different reasons? I
guess I'm thinking of the way Active Directory works, which I've
found, in my second life as a system administrator, to be both easy to
grasp and extremely flexible/powerful.
Ben
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
From: Ben Dunlap
>> Yes, they offer an additional layer of granularity on permissions.
The apps
>> I write use groups and role to limit acces to certain functionality.
The
>> roles determine functional access to records, ie what the user can do
with
>> them. The groups membership determines what records the user can see.
E.g.
>=20
> But is this substantially different from just allowing "groups" to
> determine access to functionality, /and/ access to records, and
> letting the admin create different groups for different reasons? I
> guess I'm thinking of the way Active Directory works, which I've
> found, in my second life as a system administrator, to be both easy to
> grasp and extremely flexible/powerful.
Yes it is. The extra layer allows me to be an admin in group A, only a
reader in group B, and a moderator in group C. The question is whether
you will need the extra level of control now or in the future.
Bob McConnell
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php