I think this is a very wise way to handle the situation. The fuses then become agnostic regarding how security/permissions/roles/groups/thingies are handled.
-----Original Message----- From: Steve Nelson [mailto:[EMAIL PROTECTED]] Sent: Thursday, April 04, 2002 7:12 PM To: [EMAIL PROTECTED] Subject: Re: secure tag and permissions 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 ==^================================================================
