Sure Steve,
I have no problem with that at all. At a fuse level, it seems perfectly
appropriate that it accepts and uses a simple Boolean.
But fuses aren't usually where I implement security. I do that almost
exclusively at the Fuseaction level, and at that level I am more
comfortable using a higher-level (ie business-level) concepts.
The closer I can get to coding in the language of the business user, the
better for everyone. Down at the fuse level, this is difficult to
arrange, because you also have your eye on re-use, etc. But as I move
higher up the architecture, I want to move closer to business language,
if you catch my meaning, if you get my drift.
Thanks heaps everyone.
Good topic.
See ya,
LeeBB
Steve Nelson wrote:
> Well, kind of.
>
> There are 3 areas of an FB application that can be secured: circuits,
> fuseactions and fuses. Let's ignore circuits and fuseactions and look
> specifically at a fuse, mainly because fuses have fusedocs.
>
> By doing what I'm talking about, adding a secured area to a fuse would
> require
> no more than:
>
> <in>
> <boolean name="canviewlink"/>
> </in>
>
> Not a list, not a bit, not a file call to <cf_secure> not an incoming
> UDF etc
> etc, just simply a boolean variable. Just like how a display fuse with
> an
> incoming recordset doesn't care whether you created the recordset from
> an SQL
> server or an Access server, it should also not care whether you
> generated the
> value for that boolean statement from a groups based security model, a
> permissions based model, or whether you used a list, or a bit value, etc
> etc..
>
> The point is that ANY security model can be modified slightly and come
> to an
> agreement on one thing, they can create the value of #canviewlink#.
> That's all
> the fuse cares about, nothing else. Since that value is being passed
> <IN> to
> this fuse, it needs to be passed <OUT> of another fuse.
>
> So, just like how we separate qry files from dsp files like this:
>
> <cfcase value="viewproduct">
> <cfinclude template="qry_product.cfm">
> <cfinclude template="dsp_product.cfm">
> </cfcase>
>
> We can separate security from display, like this:
>
> <cfcase value="viewproducts">
> <cfinclude template="qry_products.cfm">
> <cfinclude template="sec_editproduct.cfm"> (or <cf_secure>, it doesn't
> matter)
> <cfinclude template="dsp_products.cfm">
> </cfcase>
>
> Whether sec_editproduct.cfm or <cf_secure> or whether this is set here
> in the
> cfcase or set in some fbx_settings.cfm, it doesn't matter. The point is
> that
> we're dealing with very simple boolean values, whatever fuse you decide
> to use,
> it just has to decide whether the current user #canviewlink#, then set
> that
> value to TRUE or FALSE.
>
> gotta run, time for dinner.
>
> Steve
>
> Lee Borkman wrote:
>
> > Hmm, maybe I have misunderstood the thrust of what you are saying here,
> > Steve.Are you saying that whatever the security model used, be it Groups
> > or
> > Permissions or Colour or Crede, the "beautiful" thing about Hal's model
> > is
> > that each fuse merely expects two binary numbers:
> >
> > * the requiredProperty (eg., 0100),
> > * the userProperties (eg, 11000011).
> >
> > It doesn't matter what these properties represent - they could be atomic
> > permissions or rich group memberships, the fuse doesn't care. It just
> > compares the requiredProperty with the userProperties (BitAnd), and hey
> > presto, we have our answer.Now that. I admit, is cool.
> >
> > Is that what we were arguing about all along? I hope not. ;-)
> >
> > LeeBB
> >
> > ----- Original Message -----
> >
> > From: Steve Nelson
> > To: [EMAIL PROTECTED]
> > Sent: Saturday, April 06, 2002 6:26 AM
> > Subject: Re: secure tag and permissions
> > 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: [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
==^================================================================
