On 21 Aug 2004 at 18:18, david nicol wrote: > On Sat, 2004-08-21 at 16:00, Kurt Starsinic wrote: > > Also, when you're talking about groups of groups as above, the > > more common term of art is accounts and subaccounts. > > > > - Kurt > > While we're pitching terms, *nix, which unashamedly uses "groups" > for these things, talks about "permissions" or "perms" while > the access control list school of thought talks about the "ACL".
Yes, I'm a bit stuck in the Unix terminology, I need to do a bit more research around ACL in particular. At first glance, a lot of the ACL modules are implementing protocols to communicate with various authentication services. But something like Data::ACL covers a lot of the ground I'm thinking about. Mine adds the ability to associate code with the groups in the ACL, and uses a different mechanism for setting up the groups hierarchy. Maybe I should call it something like Tree::ACL::MethodMaker. > Permissions, privileges, capabilities are generally handled by > the environment in which a program is operating, which leads me > to the suspicion that you're operating in a CGI context. Assuming > you're using something else for the authentication phase, and > since accounting was not mentioned in your query, I'll propose > > CGI::Perms::Baird > > as something to work from. Boldly brand! Hmm. Much as I like the suggestion, I don't think it communicates much about what the module is doing! Sure, many programs operate in an environment that already provides/enforces a particular authentication mechanism. If so, my module isn't for you, it's not an interface to an authentication or authorization service. It provides an authorization service. Yes, I'm building web apps, but I don't see that the permissions management subsystem has anything to do with that environment. I happen to receive usernames and passwords from form submissions, but that's irrelevant to this module. At the moment, I'm favouring something with Tree and ACL in it, plus something like MethodMaker to indicate the code-managing aspect. Maybe Perms instead of ACL, but ACL seems to be the standard terminology. The API would look something like my $groups = ... get a tree structure ... # just like Data::ACL my $acl = Tree::ACL::MethodMaker->new( $groups ); # add some capabilities # this one is just like Data::ACL - $acl->group( 'groupname' )->add_permission( 'admin' ); # these are new stuff - $acl->group( 'groupname' )->add_abilities( edit => $coderef ); $acl->group( 'groupname' )->add_abilities( 'Some::Package' ); # not part of my module: my $user = authenticate_and_return_user( $username, $password ); # this one is just like Data::ACL - if ( $user->get_group->is_allowed( 'admin' ) { # do admin stuff } # these are new stuff - if ( $user->get_group->can_do( 'edit' ) ) { $user->get_group->edit( @args ); } if ( $user->get_group->can_do( 'create_user' ) { # Some::Package::create_user $user->get_group->create_user( @other_args ); } You could easily define pass-through methods in your user class so you can call these methods directly on the user. Cheers, d. -- Dr. David R. Baird Riverside Content Management Systems [EMAIL PROTECTED] http://www.riverside-cms.co.uk
