RE: secure tag and permissions

hal helms Fri, 05 Apr 2002 12:18:07 -0800

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

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

-----Original Message-----
From: Lee Borkman [mailto:[EMAIL PROTECTED]]
Sent: Friday, April 05, 2002 1:56 PM
To: [EMAIL PROTECTED]
Subject: Re: secure tag and permissions

That's the facts, Jack!
My conceptual model includes:

People
Groups (both application-independent "social groups"and application-specific "roles")
Business Rules

That's all there is in my authentication/authorisation/customisation world view. I could add another element called a Permission, but to me a Permission is simply the result of applying Business Rules to the Groups. What I usually do, though, is apply the Business Rules to the Groups as and when required, without actually storing the result away in some data construct called a Permission. I can do that, and sometimes do, but it's a coding decision, not a conceptual issue.

A more fundamental distinction with Hal's world view, though, is that I simply do not allow Business Rules to act directly on People (as opposed to Groups). Nor have I ever been approached by a client who has ever proposed a Business Rule that applies directly to a particular Person.

I won't try quoting Hal - the courts are over-worked enough already.

Thanks all,

LeeBB

----- Original Message -----

From: hal helms

Where Lee and I disagree is that Lee doesn't see any distinction between
isArticleReader and the set of permissions, hasReadArticlePermission and
hasSearchArticlePermission. In Lee's model, there are no such things as
independent permissions. Lest I misrepresent it, here are Lee's words:
"What's a Permission? Show me one? It's a very abstract little beastie.
Too abstract for me."

-----Original Message-----
From: Roger B. [mailto:[EMAIL PROTECTED]]

Patrick McElhaney wrote:
> That is, instead of
> <cfif hasReadArticlePermission>Read this article</cfif>
> <cfif hasSearchArticlePermission>Search this article</cfif>
>
> this works okay for you:
> <cfif isArticleReader>
>   Read this article
>   Search this article
> </cfif>

Now you have me wondering if I've been reading Lee all wrong... I never
even considered that his thinking might be along those lines. Instead, I

figured he was thinking:

<cfif isArticleReader>
     <cfset hasReadArticlePermission = true>
     <cfset hasSearchArticlePermissioon = true>
</cfif>

<cfif hasReadArticlePermission>Read this article</cfif>
<cfif hasSearchArticlePermission>Search this article</cfif>

--
==^================================================================
This email was sent to: [EMAIL PROTECTED]

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrFMa.bU4xFm
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
==^================================================================

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

RE: secure tag and permissions

Reply via email to