Hey Matt, Where can we take a look at this product?
Cheers, Baz -----Original Message----- From: Matt Robertson [mailto:[EMAIL PROTECTED] Sent: Saturday, January 07, 2006 12:18 PM To: CF-Talk Subject: Re: User, Permission Management disclaimer: I'm describing a commercial product I sell. I have users, permissions, groups and profiles. Anything you want can be assigned a permission. This could be a whole template, a single snippet of code or perhaps a number of snippets spread out amongst a variety of templates. Depending on how you apply them they could also be anti-permissions. What I call groups are something I am probably going to phase out with a recent upgrade I did to the system, and will only keep for legacy support. They were basically intended to serve the same role as permissions, except a given resource could belong to any number of groups, and a user could belong to any number of groups. If there was one match between them the user was granted permission to the resource. Since now I can have a single resource allow access to more than one permission this takes away a lot of the need for 'groups'. A profile is a collection of permissions and group memberships that can be applied in bulk to a user. The profile can then be customized individually. The user has their groups and permissions stored in memory after login. Resources either have their permissions hardcoded into the code (if protecting at the snippet level) or pulled from a database record (if building into something like page access for a cms). I wrap permission management in with application security in general. Its not just the assiggnment of permissions you have to worry about, but the circumvention of those permissions as well. cross-site scripting, SQL injection, proper storage of the user password, hint and answer, secure method of self-service password reset... I really prefer to drop in a complete security/permission system in toto. The trouble is clients always want to dumb the thing down so they don't need strong passwords etc. On 1/7/06, Dawson, Michael <[EMAIL PROTECTED]> wrote: > > Maybe I'm a bit daft, but I never really understood the logic of using > CFC roles. > > Let's say I use CFLOGIN and I assign a user to a "normal" role, but not > to an "admin" role. > > Then, I have a function with the roles attribute set to "admin". > > When the user calls a page that uses the function, it's going to throw > an exception. > > So, I then need to wrap it in a CFTRY/CFCATCH block and then determine > what to do when the exception occurs. > > If the "normal" user is not allowed to call an "admin" function, why > would I just not use application logic to determine what functions a > user can actually call? > > I have never really understood this functionality of CF: > > <cftry> > <cfset result = myAdminFunc()> > <cfcatch type="any"> > <cfset result = myNormalFunc()> > </cfcatch> > </cftry> > > When I could do: > > <cfif myUser.roles contains "admin"> > do admin stuff here > <cfelse> > do normal stuff here > </cfif> > > Am I missing the actual reason for CFC roles? > > M!ke > > -----Original Message----- > From: James Holmes [mailto:[EMAIL PROTECTED] > Sent: Saturday, January 07, 2006 6:18 AM > To: CF-Talk > Subject: Re: User, Permission Management > > I use CFLOGIN with CFC roles. This provides for the user/admin/etc > scenario and generally suffices for most of our security needs. The > authentication is done via LDAP and everything is secured via SSL. > Security checking for each page is done with IsUserInRole(), which > therefore works with memory. > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Message: http://www.houseoffusion.com/lists.cfm/link=i:4:228735 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
