Re: secure tag and permissions

[Lee Borkman]

Title: Message

I think you're confusing two issues here, H. One is whether you deal with Groups or with Permissions. The other is whether you hard-code things. Now I can certainly deal with the fuse that you have described.  It expects a Boolean variable, and, as I have explained, I can create and use variables of that form using my model.  There's no incompatibility.   But your fuse specification is equivalent to mine: <in>   <list name="groupsThatCanDeleteDocument"> </in>   I don't need to re-code my fuse when the rules change.   (We are trying the complete set of fallacious rhetorical devices - we can tick off "the Straw Man Attack" now.)    See, the one thing you haven't yet told us (I think) is how you go about determining what permissions the current user actually has.  You have to do it somewhere, I'm sure.  Most likely you do it in much the same way that I do, eg: <cfif isMember("administrators")>   <cfset canChangeThings = true> </cfif> ...or some BitWise equivalent. So your point about hard-coding is perfectly true.  I agree.  I don't hard-code.  You don't hard-code.  You avoid hard-coding by passing around Permissions as bit flags in a bit array.  I avoid hard-coding by passing around lists of Groups in a string.  I can go further if I like and create bit arrays of Permissions or bit arrays of Group memberships, but I don't usually have a need. (I do use Bit arrays for passing around other sets of flags, though.  Have a look at the wireframetool.  I have nothing against bits or against flags.  In terms of authorisation and customisation, though, it's an extra level of reductionism that seems to serve no significant purpose, while entailing an extra level of complexity for those who have to do the work.) See ya later, matey LeeBB ----- Original Message ----- From: hal helms   Lee, here's a Fusedoc showing a permission needed by a fuse. For maximal reusability and maintainability, the fuse makes no assumptions about HOW someone got a permission, whether by belonging to group A or group B or whether granted the permission without belonging to any group.   <in>   <Boolean name="canDeleteDocument" /> </in>   Here we have a concept of a permission that has no explicit connection with a user group. Any application that wants to use this fuse can do so, simply by setting a value of TRUE or FALSE for this permission. How's the value set? The fuse doesn't care. Maybe the user belongs to a privileged user group; maybe the user is the uncle of the chief programmer; maybe this is a game and the values for canDeleteDocument are generated randomly (stranger things have happened).   Or say we use the fuse in two applications. In one application, group A HAS permission to delete a document, but in another application, group A does NOT have permission to delete a document. Now, you have to go into the code and start making changes to the fuse. We used to hardcode fuseactions into fuses, but we found the introduction of XFAs made our code more adaptable and reusable. The concept of permissions as distinct from groups does the same thing for security.   ==^================================================================ This email was sent to: archive@jab.org 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 ==^================================================================