Yep. I know exactly what you mean. It still works perfectly. The boolean concept
still hold true. I'm having a hard time thinking of good examples, but here are a
couple bad examples:
Example:
-fbx_settings.cfm-
<cf_secure name="canmanageusers" ...>
<!---this is a little silly because you can just use an FailureXFA in cf_secure
--->
<cfinclude template="url_notamanager.cfm">
Or
fbx_settings.cfm
<cf_secure name="caneditarticles"...>
<cf_secure name="candeletearticles"...>
<cf_secure name="canaddarticles"...>
fbx_switch.cfm
<cfcase value="editarticles">
<!--- passes in #caneditarticles# --->
<cfinclude template="url_checkeditpermission.cfm">
<cfinclude template="dsp_editarticles.cfm">
</cfcase>
Or a simpler way to do the same thing, using the FailureXFA
fbx_switch.cfm
<cfcase value="editarticles">
<cf_secure name="caneditarticles"...>
<cfinclude template="dsp_editarticles.cfm">
</cfcase>
Essentially with boolean variables, you can add if statements anywhere you want,
in a fuse, in an fbx_switch (not recommended, pass it into a fuse), in the
fbx_settings.cfm, in the fbx_layouts.cfm etc etc. See my point?
Send me an example that you're having trouble with and let's see if we can break
the idea. Oh, yeah, one more thing... because it's based on booleans, i couldn't
give the tiniest shit what you name that variable. For example, as an architect
whether you do:
<cfif editarticles>
or you do:
<cfif articlemanager>
It doesn't matter, so if YOU want to use groups and Hal wants to use permissions,
who cares? The architect gets to decide. For this to work, we can't define the
intricacies of security, that's why Spectra's security never worked. But we can
define the parameters the security model needs to have to play well with Fusebox.
Steve Nelson
Lee Borkman wrote:
> 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
==^================================================================
