In my ideal world, the fuses should actually be identical.
Just like how we separate display from logic, we should separate display and
logic from security.
I don't know if this is the best solution, but it might work. We could slightly
modify <cf_secure> so that instead of outputting "isPermitted", it outputs a
dynamic boolean variable which would get passed into the next file. Then, we
ONLY pass boolean variables into the fuses and <cf_secure> handles what model
you're dealing with.
Like this:
<cfcase value="thecleanbathroom">
<cf_secure name="ireallygottago___mayi" UserPermissions="#mypermissions#"
model="bit" .....>
<cfinclude template="dsp_executivebathroom.cfm">
</cfcase>
That way, whether model="bit" or model="list" or model="whatever"
dsp_executivebathroom.cfm wouldn't care. The dsp_executivebathroom.cfm would
work either way because it's a simple boolean, look at this Fusedoc:
<!--- -->
<fusedoc fuse="dsp_executivebathroom.cfm" language="ColdFusion 4.5.2"
specification="2.0">
<responsibilities>
I display the virtual equivalent of a toilet, whatever that might be
</responsibilities>
<io>
<in>
<boolean name="ireallygottago___mayi" comments="This entire fuse should only
display if this value is true"/>
</in>
</io>
</fusedoc>
--->
Steve Nelson
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
==^================================================================
