You basically have a tradeoff between the complexity of managing user's roles (hundreds of roles per user can be a pain to administrate), vs the flexibility of your system. Because there is that tradeoff, I don't think there is a correct answer to your question, besides "It depends".
I don't think CF will have a problem running with a hundred roles. Just remember that is going to take up space to store all the role names in RAM for each user (a couple KB per user), but I don't think you could have enough users for that to be a problem. There was a bug posted in Macromedia Forums about CFLOGIN, I believe the problem was when you update user's roles, CFLOGOUT and then when you login again it didn't use the new roles. You might want to look into that before moving to CFLOGIN. _____________________________________________ Pete Freitag CTO, CFDEV.COM ColdFusion Developer Resources http://www.cfdev.com/ -----Original Message----- From: Matthew Walker [mailto:[EMAIL PROTECTED]] Sent: Saturday, August 17, 2002 6:57 PM To: CF-Talk Subject: Re: using cflogin roles (was Single Login - Multiple Apps) We have an existing CMS where the administration is built loosely in fusebox. So each action you can perform in the admin (and by action I basically mean item in the menu) has an associated "fuseaction" such as "EditPage" or "NewUser" or "ViewEnquiriesReport". There might be say 150 of these fuseactions, all stored in the database, but this would change from site to site as we clip on more features. Now each of these fuseactions is associated with one or more user groups. When we display menus, only the menu items associated with fuseactions permitted for that user's user group appear. But also when somebody tries to perform some action, the database is looked up to check if that fuseaction is assigned to that user group. The big advantage of this is flexibility: we can add new user groups easily, create new fuseactions and assign them to groups, disable certain features that are inappropriate or not working properly or whatever in a very fine-grained way without having to get into the code at all. We can and do also use this admin environment to maintain other completely different sites. All this means is a custom set of fuseactions. I could alternatively have different actions grouped into roles and then the roles assigned to groups, but that would seem to be making things more complex. And I would lose the fine-grained control that I need. We are about to transfer this CMS to CFMX and give it an overhaul, so we are free to use cflogin technology or not in whatever seems the best way. We could use roles to store the user's user groups (author, administrator, etc) or as the individual fuseactions associated with the user (EditPage, DeletePage, PublishPage). Or we could rethink and group individual fuseactions into roles as you seem to be suggesting. To me it seems the disadvantage of this is that two tiers of permissions are visible as user groups and roles, but the bottom tier is hidden in the code. Is there a particular physical reason why hundreds of roles shouldn't be assigned to a user or is it simply not Macromedia's vision? I can understand that the roles associated with cflogin aren't designed to work for everybody's situation, but I'm not clear on why they couldn't be used/abused in this way. Hence the question. Fusebox wasn't Macromedia's vision either of course but it seems to work. :-) ----- Original Message ----- From: "Sean A Corfield" <[EMAIL PROTECTED]> To: "CF-Talk" <[EMAIL PROTECTED]> Sent: Sunday, August 18, 2002 4:11 AM Subject: Re: Single Login - Multiple Apps > On Saturday, August 17, 2002, at 12:01 , Matthew Walker wrote: > > So for a complex app I would typically assign a permission to every action > > that could be performed, then I would be assigning various (maybe hundreds > > of) permissions to different user groups. But on top of that I would like > > to > > add or restrict individual permissions on a user by user basis. My current > > process for managing that would be for the database to be queries to find > > out if user X was allowed to perform action Y. Is it realistic to use the > > cflogin roles to store literally zillions of permissions? > > Let's be realistic about this... Most applications have a few roles / > personas / whatever and may have several groups to which users belong. For > most applications, cflogin is going to work just fine. Like all > out-of-the-box systems, it isn't a panacea. > > I don't really believe you would "assign a permission to every action". I > think in a well-designed application, you would partition operations into > categories and assign a role to each category. > > For example, macromedia.com will have a single role for all authenticated > users and then one or two sub-roles below that. On top of that, we have > one specialized application that is heavily role-based and for that > application alone, we use a custom schema to describe user roles. > > In our publishing system, we use a workflow engine to control who can do > what in terms of edit, review, make-live etc. It manages its own user > groups although it uses cflogin as the top-level framework. > > Elsewhere, we use the 'authenticated user' role to secure CFC methods. > However, we also ensure the web site's navigation flow keeps people away > from operations that they should not execute - the CFC-level security is > mostly to prevent unauthorized access via Web Services to our methods. > > Perhaps if you could be a little more specific about your application, we > can work together to design some infrastructure that will provide a good > mix of cflogin with custom group management? > > Sean A Corfield -- http://www.corfield.org/blog/ > > "If you're not annoying somebody, you're not really alive." > -- Margaret Atwood > > ______________________________________________________________________ Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.cfm FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/[email protected]/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
