> 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).
>> You can then use the same system for group-level checks.
>> For example:
>>
>> if URL.action=delete & isEntitled(UserID, "admin,member")
>> delete message
>> end if
>>
>> This is saying that "if the person is a member of the
>> admin or moderator groups, let'em delete".
> Again, I am trying to pull any group reference out of
> the templates. I want the security system to do all the
> group lookups and cross-reference it to the entitlements
> that were registered in the DB for that given template
> and then let the template know whether or not it can go
> ahead and perform the requested entitlement.
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
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
programming to make that happen. Needing to program in the association
of permission to template is enough -- although for framework apps
I've eliminated most of that work as well. This is one of the reasons
I dislike using the built-in permission features in CFC's -- that and
the fact that I don't believe the individual domain-model CFC's should
be responsible for security because that more or less breaks
encapsulation. Securtiy should be an aspect of the view/controller.
>> With this you gain the concept of inheritance.
>> In your example, for example, there's really no
>> need to have the same permissions defined multiple
>> times. Instead have permissions inherited:
> Inheritance is definately something that I'd like to
> investigate further. I know that my example was very
> poorly written, but I'd definately like to optimize
> the code so it's using inheritance instead of brute
> force to figure out who's got access to what. After
> we get through this initial conversation, I'd like
> to further investigate your logic for how groups are
> inherited (the nitty gritty). But let's leave
> that for another thread ;)
I personally dislike the idea of inheritance in this context, and
would actually encourage against it... Same with user-permissions and
user-groups (members of user group x are also members of role y and
z). I think these concepts tend to result in lots of confusion from
the people using the user-management system with very little gain.
Individual user permissions mostly results in users using only
individual user permissions and thus creating way more work for
themselves (and everyone else) because they refuse to use roles to
accomplish the task for which they're intended. Role inheritance and
user-groups just confuse people. "Okay, so user x is a member of group
y and role z but since he's a member of group y that means he's also
members of roles a and q, so my user is a member of ... what now?" ...
or "Oh he shouldn't have permission to access that, I'll just remove
him from role x ... why does he still have that permission? Which
roles have that permission? He's a member of 7 groups, how many
freaking groups have one of those roles?!"
I generally recommend just having a many-to-many relationship between
users and roles (so a single user can be in several roles) and omit
all the other fancy bells and whistles that could be introduced here,
such as individual user permissions, inheritance or user groups. If
the users can understand the simple principals behind roles, this is
the easiest way for them to manage the application users.
>> 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
course, and it wouldn't be too difficult to do in-page, but it
definately wouldn't be encouraged. The RuleManager components do allow
member roles to be used as criteria for business logic, but again a
user must select the roles they want which are then stored -- it's
never coded into the page.
>> I still really don't see how that's any less complex
>> that what I've presented as the "standard model".
>> You're adding a lot of complexity under the covers to
>> track file names when you really don't need to in my
>> opinion: the templates still need to know which
>> entitlements they need (since they have to check for
>> them) and since they need to know there's no reason to
>> store them in the database (as least that I can see).
> Hehehe, that's the rub, it isn't any less complex, it's
> just more flexible by not having to edit the template-
> level code to tell it what it's allowed to do. It's all
> controlled centrally. My goal is to allow all
> entitlement/group association to happen in a GUI instead
> of having to edit the templates to say what a template
> is allowed to do.
> The only requirement for a template is to tell the system
> what entitlements are available for that given template
> so they can be registered in the DB and the security
> system will then allow you to assign permissions to each
> of those entitlements through a GUI.
It really does sound to me like you're recreating the Members onTap
security model actually...
> You know, thought of an idea. I could still use the
> system that I described above. It would still register
> every template with the security system and that
> template's specific entitlements. Then, when a user
> first logs in, it will load up all the entitlements
> that the specific user has into a session list like
> you mentioned. So now, instead of it hitting the DB,
> it will just hit the memory. Not quite as dynamic, but
> it would definately be faster and memory's cheaper than
> a faster DB. I could probably make a flag for the
> security system to reload a logged-in user's entitlement
> list if the permissions were changed.
I would recommend not loading that data into the session scope. Load
it into the application scope... In your custom tag, check to see if
the necessary data for the current request is loaded into the
application scope and if not load it. This will do two things for you
-- first it will allow you to keep the system just as dynamic (i.e.
user won't have to log in again before changes are effective, since
your central gui for changing permissions will load new data over the
existing application scope data), and it will eliminate the overhead
of executing the db queries on each page. You won't need to do
back-flips over the session scope (setting flags) to get things
reloaded, and the data will actually be in a scope that's relevant to
it -- role-permission information isn't relevant to a user, so it
doesn't really belong to the session scope, and will inflate your
memory consumption unnecessarilly if you put it there.
> 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.
s. isaac dealey 954.522.6080
new epoch : isn't it time for a change?
add features without fixtures with
the onTap open source framework
http://www.fusiontap.com
http://coldfusion.sys-con.com/author/4806Dealey.htm
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
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:217329
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=11502.10531.4
Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
