|
This conversation has been awesome. It's become very clear to me that the
Fusebox standards committee needs to define a specification for Fusebox
security, and hopefully the community will create different security implementations
that follow that spec. That would be a beautiful thing.
btw, I heard through the FB council grapeline that voting for the steering
committee will be launched soon. Anyone out there that has not become an
"Official Fusebox Member", do so soon so you can help us define what the
future of Fusebox is.
Steve Nelson
hal helms wrote:
I
give up, Lee. I'm
wearied by the argumentums ad hominem (speaking of logical fallacies). If
you don't see the need for permissions, then I accept that for you that
need doesn't exist. Live long and prosper.
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 -----
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: [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
==^================================================================
|
