User, Permission Management
Hi, I'm curious how people are handling session/user/permission/login management these days... Have most of you implemented your own custom solutions? Do a lot of people use cflogin? Are people using CFC roles? How are people handling checking permissions for each page? Do you check against data stored in memory? Do you query on each request? Let's say that there are regular users and admins, how verify which one they are? Just curious, Cheers, Baz ~| Message: http://www.houseoffusion.com/lists.cfm/link=i:4:228688 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
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. On 1/7/06, Baz [EMAIL PROTECTED] wrote: Hi, I'm curious how people are handling session/user/permission/login management these days... Have most of you implemented your own custom solutions? Do a lot of people use cflogin? Are people using CFC roles? How are people handling checking permissions for each page? Do you check against data stored in memory? Do you query on each request? Let's say that there are regular users and admins, how verify which one they are? -- CFAJAX docs and other useful articles: http://jr-holmes.coldfusionjournal.com/ ~| Message: http://www.houseoffusion.com/lists.cfm/link=i:4:228691 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
RE: User, Permission Management
I have users, groups, resources and permissions. And a nice GUI to manage it
all.
A resource (such as user management, product management) has permissions
created for it.
A group has resources assigned to it
A user is in a group or groups.
When a user logs in, all permissions for all groups he is a member of are
loaded into session.permissions.
In my code I use a UDF to check that a user has permission to perform a
function or view a page.
cfif request.hasPermission('permission name')
Allow content
cfelse
cfoutput#request.noaccess#/cfoutput
/cfif
--
Snake
-Original Message-
From: Baz [mailto:[EMAIL PROTECTED]
Sent: 07 January 2006 10:32
To: CF-Talk
Subject: User, Permission Management
Hi,
I'm curious how people are handling session/user/permission/login management
these days...
Have most of you implemented your own custom solutions? Do a lot of people
use cflogin? Are people using CFC roles?
How are people handling checking permissions for each page? Do you check
against data stored in memory? Do you query on each request? Let's say that
there are regular users and admins, how verify which one they are?
Just curious,
Cheers,
Baz
~|
Message: http://www.houseoffusion.com/lists.cfm/link=i:4:228692
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
RE: User, Permission Management
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:228702 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
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:228712 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
RE: User, Permission Management
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
RE: User, Permission Management
Here's a few screenshots of how mine works. http://www.satachi.com/images/evolver/permissions.gif http://www.satachi.com/images/evolver/groups.gif http://www.satachi.com/images/evolver/users.gif Russ -Original Message- From: Baz [mailto:[EMAIL PROTECTED] Sent: 07 January 2006 21:54 To: CF-Talk Subject: RE: User, Permission Management 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:228737 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
Re: User, Permission Management
http://mysecretbase.com/AMPro2_screenshots.cfm will get you to a view of the two admin screens. More stuff linked on the menu at left. I have been buried under some pretty well-paying work for months so I haven't had a chance to redo the Flash movie, or the tutorials or all of the screen shots devoted to v1.x, which had a very basic interface which matched up wiith the product's $29.95 price. I needed something a lot more intuitive and v2 was the result. Been using it for some time, and its been available to reg users for quite awhile. I need 3-5 days of free time to rewrite the docs and the pretty stuff, but anyone who understands the v1.0setup can get up to speed on v2 pretty fast (I think/hope). -- --mattRobertson-- Janitor, MSB Web Systems mysecretbase.com On 1/7/06, Baz [EMAIL PROTECTED] wrote: 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:228740 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
Re: User, Permission Management
They are great when sharing a CFC with another developer. They add a level of self-documentation and prevent someone who doesn't read documentation from incorrectly providing people access to the wrong things. It'a about keeping the CFC self-contained and ensuring the integrity of the app in the business logic rather than hoping the developer gets it right in the interface logic or elsewhere. On 1/8/06, Dawson, Michael [EMAIL PROTECTED] wrote: Maybe I'm a bit daft, but I never really understood the logic of using CFC roles. -- CFAJAX docs and other useful articles: http://jr-holmes.coldfusionjournal.com/ ~| Message: http://www.houseoffusion.com/lists.cfm/link=i:4:228745 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
RE: User, Permission Management
Good points in favor of Roles James. To extend M!ke's previous cftry/cfcatch example for handling roles, what happens when many roles exist - maybe 5, 10 or 100... Does people's code actually end up looking like this: !--- admins --- cftry cfset result = myAdminFunc() cfcatch type=any !--- power users --- cftry cfset result = myAdminFunc() cfcatch type=any !--- users --- cftry cfset result = myAdminFunc() cfcatch type=any !--- guests --- cftry cfset result = myAdminFunc() !--- anonymous --- cfcatch type=any cfset result = myNormalFunc() /cfcatch /cftry /cfcatch /cftry /cfcatch /cftry /cfcatch /cftry Cheers, Baz -Original Message- From: James Holmes [mailto:[EMAIL PROTECTED] Sent: Saturday, January 07, 2006 7:35 PM To: CF-Talk Subject: Re: User, Permission Management They are great when sharing a CFC with another developer. They add a level of self-documentation and prevent someone who doesn't read documentation from incorrectly providing people access to the wrong things. It'a about keeping the CFC self-contained and ensuring the integrity of the app in the business logic rather than hoping the developer gets it right in the interface logic or elsewhere. On 1/8/06, Dawson, Michael [EMAIL PROTECTED] wrote: Maybe I'm a bit daft, but I never really understood the logic of using CFC roles. -- CFAJAX docs and other useful articles: http://jr-holmes.coldfusionjournal.com/ ~| Message: http://www.houseoffusion.com/lists.cfm/link=i:4:228746 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
Re: User, Permission Management
I don't handle roles that way. I check to see if the user is in an appropriate role in the interface code, with IsUserInRole(); if the CFC throws a roles error it means there's a programming error so I let it fail to my CFERROR handler template (which emails me and tells me to fix the code). This should all show up in testing so by the time the user gets to the product there should be no CFC roles errors. On 1/8/06, Baz [EMAIL PROTECTED] wrote: Good points in favor of Roles James. To extend M!ke's previous cftry/cfcatch example for handling roles, what happens when many roles exist - maybe 5, 10 or 100... Does people's code actually end up looking like this: !--- admins --- cftry cfset result = myAdminFunc() cfcatch type=any [snip] -- CFAJAX docs and other useful articles: http://jr-holmes.coldfusionjournal.com/ ~| Message: http://www.houseoffusion.com/lists.cfm/link=i:4:228747 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
RE: User, Permission Management
I implement a template based permission infrastructure where basically users can either access a page or not. I've personally never bumped into a case that required CFC level permission control... In what kind of situations do people find this valuable? Some non-cfc in-page granular permission control I HAVE needed: - Displaying links on a page to sections that a specific user has access to. But I wouldn't write a new method for every possible role, I just check each link to see if the user has perm to it or not. - Limiting returned recordsets: Again, I wouldn't write a new method for EVERY role, there are too many, I would just pass in some arguments and use them to filter. Especially since it seems like 99% of your CFC would be the same besides some WHERE clause or a couple of conditions. - There are several others, but I have to go pick up my friend from the airport. Cheers, Baz -Original Message- From: James Holmes [mailto:[EMAIL PROTECTED] Sent: Saturday, January 07, 2006 7:35 PM To: CF-Talk Subject: Re: User, Permission Management They are great when sharing a CFC with another developer. They add a level of self-documentation and prevent someone who doesn't read documentation from incorrectly providing people access to the wrong things. It'a about keeping the CFC self-contained and ensuring the integrity of the app in the business logic rather than hoping the developer gets it right in the interface logic or elsewhere. On 1/8/06, Dawson, Michael [EMAIL PROTECTED] wrote: Maybe I'm a bit daft, but I never really understood the logic of using CFC roles. -- CFAJAX docs and other useful articles: http://jr-holmes.coldfusionjournal.com/ ~| Message: http://www.houseoffusion.com/lists.cfm/link=i:4:228749 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
