Re: secure tag and permissions

Fri, 05 Apr 2002 16:38:08 -0800

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 -----

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
==^================================================================

Reply via email to