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

[download]
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'

[download]
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";
}

[download]
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

[download]

In reply to Re: User and Group Management by vladb
in thread User and Group Management by random

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.