i just played around with the modifications to <cf_secure>, they seem to work great. I'll send it over to you and you can decide whether you want to release it to the public, since it was your tag to begin with.
I just thought of another elegant reason for this approach. You originally have <cf_secure> with an ending tag, that way you can wrap areas of a fuse with <cf_secure> and effectively hide those areas of the fuse from people that do not have the permissions. By using this slightly modified method, you no longer need that ending tag. Basically <cf_secure> just outputs a bunch of boolean variables and you do simple <cfif> statements in your fuses to hide those areas. By not requiring an ending tag <cf_secure> can now very easily migrate to other languages, PHP, JSP, ASP etc. Steve Nelson hal helms wrote: > 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 ==^================================================================
