> -----Original Message-----
> From: S. Isaac Dealey [mailto:[EMAIL PROTECTED]
> Sent: Sunday, September 04, 2005 4:25 PM
> To: CF-Talk
> Subject: Re: Question about my security system
>
> > Here's the problem - what if there is a template called
> > users.cfm for modifying user accounts. Now that user
> > will also have edit, delete, post, and read access
> > unless you differentiate the entitlement sets like:
> > messageedit, message_delete, message_post, message_read,
> > user_delete, user_edit. What I'm saying is that not
> > every template on the site uses the same set of
> > entitlements. While one template can perform one set
> > of actions, another template might be doing something
> > completely unrelated.
>
> I'm sure that's how entitlements are differentiated in Jim's apps
> (message_edit, user_edit, etc).
Nope. ;^) My apps are dumbasses.
The system just allows you make labels for things - you get granular and do
tasks or generic and do groups or whatever - there's no difference in
concept.
So far I've never needed more than generic "Admin", "Editor", "Member" and
"Visitor".
I know - I've led a sheltered life.
It's also a tiny bit frustrating that spent so long modeling and building
this security system and all I've ever needed from it is a four-way switch.
;^)
> I personally hate security models that place role names in the page...
> imo the only thing an individual page should know about is the
> permission, and maybe the user (for performing impersonation or
I'm having the same problem here: I don't see any conceptual difference
between a role and permission. The difference is all in the labeling and
physical concepts they represent, not the system level.
> otherwise checking to see if another user is permitted to perform a
> given task). And it's for the same reason you cite -- you can't then
> add roles without editing tons of different templates. There should be
> a single, logical and easy to use tool for updating user-roles and
> role-permissions in one place, and it shouldn't require extra
But you do have to create extra programming to add permissions... so what's
the difference?
> >> The key is that all of that complexity (groups of
> >> groups, etc) is abstracted away in a service-level
> >> component. You need to know the group or task you
> >> want to perform ("delete" or "member") but that's
> >> it - you ask the system "can he?" and it says
> >> "yes" or "no".
>
> > the requirement of knowing group or task is
> > specifically what I was trying to pull out of the
> > template-level code.
>
> Yeah, I would shy away from any system that recommends an individual
> page request to know if the current user is a member of a specific
> role to handle permissions instead of asking about a specific
> permission. The Members onTap component has tools to determine that of
Again - I'm just not seeing the difference. Whether page asks "can he
delete" or "is he an admin" is just syntax - they're both the same concept.
> > I just wonder how big of a memory hit that would be if I
> > have 7000 users with a pretty long entitlement list
> > loaded for every user. It'd probably be smart to use
> > some kind of abbreviation notation.
>
> Yep, see above... Store it in the application scope -- I'd even store
> the list of roles for a given user in a struct in the application
> scope and just compare that to a userid stored in the session... It'll
> save you a lot of both memory and sanity.
This is how I do things. It does work nicely.
The security system is a self-contained service. When a user logs in it's
given an identification key (I use a version of the CFTOKEN). Only that key
is stored in the session - and any data retrieved from the security service
is found by passing it the key.
The security service knows nothing about the application and the application
knows damn little about the security service. The service can be loaded
into the application scope or the server scope: since all of the data caches
are properties of the instantiated component it's up the application where
it wants to persist it - the security system couldn't care less.
Jim Davis
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
Logware (www.logware.us): a new and convenient web-based time tracking
application. Start tracking and documenting hours spent on a project or with a
client with Logware today. Try it for free with a 15 day trial account.
http://www.houseoffusion.com/banners/view.cfm?bannerid=67
Message: http://www.houseoffusion.com/lists.cfm/link=i:4:217336
Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4
Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4
Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
