So I've got Hal's security model working on one of my circuits and it does fit our need perfectly. My question is relating to the proposed spec mentioned in the document: The Impossibility of a Universal Security Model. It details the possibility of an extra step in the core file that basically does the same thing for fbx_permissions as it does for fbx_settings. Is anyone currently doing this?
I'm trying to wrap my head around initializing permission contexts throughout each circuit. I know I will need a seperate permissions structure inside of each circuit; it will associate groups with the fuseactions they're permitted to call. I think I have it down, but I was looking for a little nudge from one of the experts here:
<!--- books/app_permissions.cfm (this could be fbx_ if it were in the extended FB spec, currently I'm just including it from books/fbx_settings) --->
<cfscript>
request.Permissions.books = structnew();
request.Permissions.books.listBooks = 1;
request.Permissions.books.addBooks = 2;
request.Permissions.books.delBooks = 4;
</cfscript>
<cfset bookViewers =
request.Permissions.books.listBooks>
<cfset bookAdmins =
request.Permissions.books.listBooks +
request.Permissions.books.addBooks +
request.Permissions.books.delBooks>
<!--- depending on their login session, assign them to the pertinent group --->
<cfif session.sessionStruct.isAdmin EQ 1>
<cfset request.CurrentUser.permissions = bookAdmins>
<cfelse>
<cfset request.CurrentUser.permissions = bookViewers>
</cfif>
I will do the same thing in my other circuits app_permissions and so on? In a nested situation (for instance admin/books), admin would have the Permissions.admin structure, while books would have the Permissions.books structure - no risk of overlapping each other. If I needed to use cf_secure in the admin's layout file, it's permissions structure will still be preserved.
Dah. just writing this email helped me understand... sending anyway for future searches, noobies, etc. Any comments are appreciated.
Adam.
> -----Original Message-----
> From: hal helms [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, April 04, 2002 4:08 PM
> To: [EMAIL PROTECTED]
> Subject: RE: secure tag and permissions
>
>
> I see your point, but simply don't find your model robust enough.
> Apparently, you find it works fine. I'm happy to leave it there.
>
> -----Original Message-----
> From: Lee Borkman [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, April 04, 2002 4:54 PM
> To: [EMAIL PROTECTED]
> Subject: RE: secure tag and permissions
>
>
> Now you are confusing UserGroups (independent of applications) with
> Roles (dependent on Applications). For shame!
>
> The ArticleReaders "group" only exists in the context of the
> ProduceMagazine application. In other words, ArticleReaders
> is simply a
>
> Role, ie an application-specific-group. It can have no
> bearing on how
> much John gets paid, because the ArticleReaders Group doesn't
> even exist
>
> in the context of the Payments application.
>
> Sorry about the ambush, but remember- my friends are armed.
>
> More after brekkie,
> LeeBB
>
> hal helms wrote:
> > Wait a second! You swoop down, tell me I'm guilty of a
> logical fallacy
>
> > and then don't answer my points? What is this -- ambush posting?
> >
> > Being able to read articles means just that: he has
> permission to read
>
> > articles. Let's say there's a group called "Article
> Readers" that also
>
> > have that permission. John and the Article Readers share that
> > permission, but don't belong to the same group. For example, the
> > Article Readers get emailed notices of new articles and get
> paid twice
>
> > as much as John. That is a big difference: just ask John.
> >
> > And no, I certainly do not think that questions about the nature of
> > being have little bearing on the real world. Those are some of the
> > most important questions that we ask and the answers we
> come up with
> > shape our experience of the world in a profoundly real way.
> >
> > -----Original Message-----
> > From: Lee Borkman [mailto:[EMAIL PROTECTED]]
> > Sent: Thursday, April 04, 2002 4:14 PM
> > To: [EMAIL PROTECTED]
> > Subject: Re: secure tag and permissions
> >
> >
> >
> > Well, as I say, you have stated this basic point before, and it
> > continues to elude me ;-)
> >
> >
> > For example, you can grant John the single permission of
> being able to
>
> > read articles. You do this by setting one of the Bit flags
> in John's
> > permission array. I do it by adding John to the
> ArticleReaders group.
>
> > What's the difference?
> >
> >
> > You complina that I am blurring the distinction between Groups and
> > Permissions. I don't believe I am. I simply maintain that Group
> > Membership is the only quality needed to derive Permissions (eg to
> > figure out if John can read articles). By treating Permissions as
> > though they have some independent existence outside of Group
> > membership, I believe that *you* confuse the matter ;-)
> >
> >
> > What's a Permission? Show me one? It's a very abstract
> little beastie.
>
> > Too abstract for me. You talk about assigning John a permission
> > without assigning him to a group - I say that's a non-meaningful
> > concept, like a side-salad without a meal.
> >
> >
> > Still, as I say, I haven't seen any functional difference
> demonstrated
>
> > yet. Moreover, if I receive a Fusedoc created by you, Hal,
> I can code
>
> > the fuse perfectly well using permissions and bitMath. I
> consider the
>
> > two views to be functionally equivalent, but I think one of them's
> > just a little stange.
> >
> >
> > Anyway, it's an ontological, metaphysical problem, and like most of
> > those, has little bearing on the real world. (I know you disagree).
> >
> >
> > Thanks,
> >
> >
> > LeeBB
> >
> >
> >
> >
> > ----- Original Message -----
> >
> > From: hal helms <mailto:[EMAIL PROTECTED]>
> >
> > I think you're missing a very basic point here, Lee. I am
> NOT saying
> > that John, since he has permissions to read and write
> articles, is a
> > manager. I'm saying that John has those permissions. So do
> the group
> > known as managers. I can grant John these permissions
> without making
> > him a member of any group. You cannot. Without the separation of
> > permissions and roles, you have no way of granting John those
> > permissions other than making him a member of a group.
> >
> > ...
> > And, in contradiction to what you state, I completely agree that a
> > group is something different than the sum of its permissions. One
> > attribute of a group is what permissions it has; another
> might be the
> > color of the background used. Maybe members of the Travellers group
> > have stuff output for Pocket PCs. My method draws a true
> distinction
> > between the two; by mixing roles and permissions, the
> distinction is
> > blurred.
> >
> >
> >
> >
> >
> >
> >
>
>
>
>
>
==^================================================================ 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 ==^================================================================
