I was *really* hoping you were going to tell me something like that,
Lee. ;>
Yes, you and I are speaking the same language using different words. I
don't believe in direct assignment of permissions to the user. I see it
like this:
Permissions are pointers to activities in the application.
Roles are collections of permissions.
Users may be assigned one or more roles.
Now, the obvious objection to this approach is the case where the boss
says, "I want Mary to be a Manager, but I want her to also be able to
read everyone else's schedule." Reading all schedules is an Executive
permission, but the boss doesn't want Mary to have all Executive
permissions, just that one. This is (I believe) why Hal champions a
combination of roles and individual permissions. (Correct me if I'm
wrong, Hal.) Aristotle aside, I just think the design of roles should
be one of the things included in the application design, right along
with background colors and fonts. Using this approach, every user's
needs should be represented by a role.
- Jeff
On Thursday, April 4, 2002, at 10:05 AM, Lee Borkman wrote:
> I think you mistake me for a fool, Jeff, if you think I really hard-code
> in group names like that.
>
> What I actually do is exactly equivalent to what you do... In the
> initialisation templates for the app, I initialise List variables to
> hold the required Group names. You create BitArrays of Permissions. We
> neither of us hard-code the Group names or binary numbers into our
> fuses.
>
> If I really want the ultimate in BitWise performance, then I'll just
> turn my Group Membership lists into BitArrays of GroupMembership flags;
> you don't need to equate BitWise maths with Permissions and Group
> Membership with text, as you can use text or bits to represent both.
>
> Just show me the Fusedoc and the code for a fuse that is secured using
> BitWise Permissions, and I'll show you the equivalent Fusedoc and code
> using Group membership. Then we can compare notes ;-)
>
> See ya,
> LeeBB
>
>
> Jeff Peters wrote:
>> So you do something like this:?
>>
>> <cfif (myRole EQ "Admin") OR (myRole EQ "SuperUSer") OR (myRole EQ
>> "ITAudit")>
>> Run this bit of secured code
>> </cfif>
>>
>> Besides being horribly inefficient, it means you also have to change
>> your code to add a new role. On the other hand, if you use roles in
>> conjunction with permissions assigned in the database, all you need to
>> do to add a new role is assign it permissions in the database--no
>> change
>>
>> to code. So the above example becomes:
>>
>> <cfif BitAnd(myPermissions,thisTaskMask) EQ thisTaskMask>
>> Run this bit of secured code
>> </cfif>
>>
>> and it never changes from the time you write it 'til the system is
>> superseded by Steve's next-generation thought-response system. ;>
>>
>> - Jeff
>>
>> On Thursday, April 4, 2002, at 02:27 AM, BORKMAN Lee wrote:
>>
>>> Hmm, I'm generally with John on this one. I use the names of Groups,
>>> eg:
>>>
>>> IF you are a member of (WWRAdmin OR SuperUsers OR ITAudit) {
>>> Run this bit of secured code
>>> } else {
>>> Call police
>>> }
>>>
>>> Hal and I have argued about this on many occassions, but I think we
>>> simply
>>> have a conceptual gap. Hal talks about permissions, I talk about
>>> roles. We
>>> don't *connect*. It's a pradigm thing.
>>>
>>> I am *almost* sure that the two approaches are actually functionally
>>> equivalent, but I know which I prefer ;-)
>>>
>
>
>
==^================================================================
This email was sent to: [email protected]
EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrFMa.bV0Kx9
Or send an email to: [EMAIL PROTECTED]
T O P I C A -- Register now to manage your mail!
http://www.topica.com/partner/tag02/register
==^================================================================
