Here is what I do in my case

users are assigned none to many groups

groups are implicitly assigned none to many "Security Tasks" (This also
includes whether the group has permission to Select, Insert, Update, or
Delete or any combination of this)

to further compound things, Users can explicitly be assigned to none to many
of these "Security Tasks" (This is an override, and will override all
implicitly granted group permissions for the task on a case by case basis,
this also includes whether the group has permission to Select, Insert,
Update, or Delete or any combination of this)

In my code I basically use something similar to Hals cf_secure that handles
my security routine.

What it does is look to see if the security structure that is created for
new users, or on login exists (if the key for the security task is there,
they have an implied permission to access.  I also have Select, Insert,
Update, and Delete pemissions to check for, these may or may not be used to
secure the site, but I them out to be used).

Essentially, The only thing that is hardcoded is the "security task" which
is the same thing you have hardcoded.

Within a secured block of code, if I need to check for the Select, Insert,
Update, or delete permissions, i can, by simply doing <cfif hasSelect>,
<cfif hasInsert>, <cfif hasUpdate> or <cfif hasdelete>

This whole thing allows me to:
secure based on "security task" name, or based on allowed or denied for that
"security task".

I think that about covers it.  



-----Original Message-----
From: Jeff Peters [mailto:[EMAIL PROTECTED]]
Sent: Thursday, April 04, 2002 8:35 AM
To: [EMAIL PROTECTED]
Subject: Re: secure tag and permissions


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 ;-)
>
> See ya,
> LeeBB
>
>
> -----Original Message-----
> From: hal helms [mailto:[EMAIL PROTECTED]]
>
> John is in rare form today, first urging people to add code to their
> prototypes and now suggesting that we abandon Bit math because it's too
> much effort? I suspect someone has kidnapped my friend, John, and is
> making him type these crazy things.
> ...
>
>
> IMPORTANT NOTICE:
> This e-mail and any attachment to it is intended only to be read or 
> used by
> the named addressee.  It is confidential and may contain legally 
> privileged
> information.  No confidentiality or privilege is waived or lost by any
> mistaken transmission to you.  If you receive this e-mail in error, 
> please
> immediately delete it from your system and notify the sender.  You must 
> not
> disclose, copy or use any part of this e-mail if you are not the 
> intended
> recipient.  The RTA is not responsible for any unauthorised alterations 
> to
> this e-mail or attachment to it.
>
>
>

==^================================================================
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
==^================================================================


Reply via email to