Re: secure tag and permissions

[Lee Borkman]

Yes, Steve.  Permissions-based fuses can work with any higher-level security model.  If the higher-level model does not inherently include the notion of Permission but is Groups-based, then you just need a little piece of code to translate the Groups into permissions.  Cool. But wait, Steve.  Groups-based fuses can work with any higher-level security model.  If the higher-level model does not inherently include the notion of Groups but is Permissions-based, then you just need a little piece of code to translate the Permissions into Groups.  Cool. The two models are completely equivalent.  I can switch back and forth between the two, both in my head and in my code.  I can choose which view is more appropriate, more manageable, and I can change my mind at a later date.  For now, I choose to work predominantly in the view that emphasises the relationship between Business Rules and Groups.  This is view that I find intuitive.  Essentially, I get to code directly in the language of the Business domain - something that all you Pragmatic Programmers might appreciate, believe it or not. See you guys soon, LeeBB ps., sorry to get feisty, guys, it's the hormones, you know. ----- Original Message ----- From: Steve Nelson   While I don't agree with your method of security, I would never say it's wrong...... if you would change one minor minor thing for me. First of all, compare these: 1) <cfif isMember(groupsthatCanReadArticles)> 2) <cfif userhaspermissions(listofpermissions, canreadarticles)> 3) <cfif listfind("canreadarticles, caneditcarticles, candeletearticles", "canreadarticles")> 4) <cfif canreadarticles> 5) <cfif articlereadergroup> Now, out of those 5, which are tied to one specific security model and which are not? 1, 2 and 3 are. 4 and 5 have NOTHING to do with any particular security model. They are merely boolean values. What I'm asking that you do, is ignore the fact that you check a series of groups and Hal checks a series of permissions. It honestly doesn't matter, it's a matter of semantics. Both methods can be boiled down to simple boolean variables. Your fusedocs, fuseactions and circuits will define the necessary boolean variables it needs to work, and your security model will define those variables. It's that simple. When you realize the true power of what Hal is suggesting, the only thing you have to do is unplug your security model and plug another one in it's place, your fuses, fuseactions and circuits will (should) continue to work like they did before.   ==^================================================================ 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 ==^================================================================