Re: User and Group Management

[vladb]

I have written a 'Group/User Management System' (GUMS) at work here that is still in wide use. Most of my code is in CFML however. I have a dozen or so CFML custom tags that manage data in the database. I too have a smaller Perl interface to the same data.

My system was designed to be the user priviledge and access skeleton of any application. Basically, you are allowed (and encouraged) to build special 'node' trees. There's also a pool of users and various groups which could be assigned to any specific node. A user or a group is 'linked' to a node by assigning given user/group a certain 'permission' to that node. My system is flexible enough and you can inherit access trees from one aplication to another. Same goes for various users and groups.

Unfortunately, I don't have much time at the very moment to go into the details of my design, but if you express enough interest I could delve into it some more ;-). Eventually, I'm hoping to make into a standalone Perl module, if only time allows...

Update Consider a web application which allows its users to perform the following tasks:

1. view client reports (client page/section)
2. edit client information (client page/section)
3. notify clients (email page)

An example user/group access node tree for such application could look like this:

root --+
       |
       +--- client page
       |
       +--- email page

Now, considering you have these users:

1. Vlad -- your boss, he's got to be allowed to do just about anything.
2. Bill -- clerk; can view clients only.
3. Joe -- Bill's manager; can view clients and edit clients.
4. Sam -- marketing guy; can email direct marketing etc.

So, in view of this, you'll do the following assignments:

Vlad --> 
     Node: /root
     Permission: 'All'

Bill --> 
     Node: /root/client page
     Permission: 'View'

Joe  -->
     Node: /root/client page
     Permission: 'Edit', 'View'

Sam  -->
     Node: /root/email page
     Permission: 'All'

Having set up a satisfactory user access 'skeleton' for your new application, using GUMs Perl interface module, verifying permissions for each user that comes to your web application is as easy as simply invoking a method of the module to verify user priviledges against any given access tree:

use GUMS;
# initialize DBI database...

# you retrieve user name from a cookie or
# database here...

# now, veirfy permissions:
my $res = GUMS::verify_user_perm(
               dbh => $dbh,
               app_name => 'client_management_tool',
               node_path => "/root/$app_page",
               user_name => $user_name,
               perm => 'Edit'
             );

unless ($res) {
   print "$user_name lacks 'Edit' permission to access/use this page.\
+n";
}

Of course, there are numerous other ways to structure and manage the access tree. For the most part, I leave this up to an individual developer (at my work) to do as he/she pleases. GUMS was designed to be flexible. Setting things up is relatively straightforward through a GUMS web interface (also built in Coldfusion). From my experience, I've noticed that some developers prefer to structure their access nodes to correspond to major components of their applications. Whereas others bring it one abstraction layer up... Normally, once your access tree is implemented and appropriate GUMS code is placed in your application code, managing user access to your application should be a trivial task. At work, either developers or individual application managers simply follow to my GUMS web application, which allows them to do pretty much anything. In fact, I use GUMS to protect the GUMS web application as well! ;-)

_____________________

# Under Construction