First off, It was nice to finally get a chance to meet everyone that I
did at YAPC::NA this week. For those of you I didn't meet, I'm sure
there will be another chance.
Secondly, admittedly, I've been pretty wrapped up in my own stuff at
work lately and hadn't had a chance to see all the create work going on
with C:A Plugins until I saw Michael Peters session earlier today. Also,
having a chance to sit down with a couple other from the list and chat
about the kinds of things that we'd like to see C:A (or at least
C:A:P's) be able to do got me pretty excited.
Anyways, I came back to my office after the conference and searched
around my existing code to see what "neat" things I had working that
might be useful as a C:A:P. I also noticed this Request for Content on
the C:A wiki.
* List possibilities to do authorization/login and to limit runmode
access to specific users. And how to dynamically build
menu/navigation so that a particular user only sees what he's
allowed to do.
Well, the first part isn't always easy, so I skipped it. Plus I think
Michael Graham & Richard Dice have spent way more time contemplating it
then I would have. The second part however, "Limit runmode access to
specific users and dynamically build menu/navigation, etc, etc" I found
particularly interesting because I've done it, rather easily.
So off I ran to start coding my Plugin "RMAuth", here it is with a quick
explanation, caveats and a couple things I'd like to do with it, any
comments, suggestions and criticisims are greatly appreciated.
-[code]------------------
http://www.unobserved.org/rmauth/cgi-bin/lib/CGI/Application/Plugin/RMAuth.pm
(actual C:A plugin - Cees, I stole a bunch of your C:A:P:Session config
and exporter code)
http://www.unobserved.org/rmauth/cgi-bin/lib/MyProject/Base.pm
(project base class)
http://www.unobserved.org/rmauth/cgi-bin/lib/MyProject/Books.pm (books
module)
http://www.unobserved.org/rmauth/cgi-bin/lib/MyProject/Authors.pm
(authors module)
http://www.unobserved.org/rmauth/cgi-bin/permission.xml (xml based
permission file)
-[demo]-----------------
http://www.unobserved.org/scripts/books.cgi (demo site)
-[info]-------------------
http://www.unobserved.org/rmauth/ (this email as a webpage)
http://www.unobserved.org/rmauth/rmauth.tar.gz (full demo project download)
- I don't have pod in there yet, but I do have some decent code comments.
- I am using an XML file for storing permission, but that's one of the
things I'd like to allow more flexibility in.
- Calling rmauth_init() needs to be done from inside the actual package
that you want auth done on, i.e. it can't be called from a super class
(at least not yet), so I just have it in the setup();
$self->rmauth_init ( AUTH_XMLFILE => 'permission.xml', UNAUTH_RUNMODE =>
'denied' );
AUTH_XMLFILE is the path to the xml permission file
UNAUTH_RUNMODE is the name of the run mode to be called using
$self->prerun_mode() if access has been denied.
- You don't need a base class for this to work plugin to work, you can
just include the use statement in your module
use CGI::Application::Plugin::RMAuth;
- For demo purposes I have one single permission.xml file that the code
uses. obviously you would want to dynamically set this init option as to
which permission file was loaded when dealing with multiple users,
otherwise you wouldn't really be setting user based permissions.
- I have included a couple of convienence functions:
rmauth_this_permit() & rmauth_full_permit()
returns a simple hash of which run modes the user is permitted to access
for the current package. This hash could be useful for including as a
param() sent to an html::template (etc) file, which in turn could
contain <tmpl_if name='rmauth.edit'>Show Edit Button</tmpl_if> style mark-up
(see explanation of differences in RMAuth.pm)
rmauth_last_denial()
returns the name of the run mode the user tried to access but was
denied. (see rm_denied() in Base class)
- in the permissions.xml file i used MyProject.Books instead of
MyProject::Books because more then one : in an xml element name is
invalid XML. This is a small caveat. I choose XML files for my demo and
proof of concept because it's similar to what I'm currently using,
again, flexibility in the future.
- also in the permission.xml file
<rmauth_everything>1</rmauth_everything> will grant access to all run
modes within a certain module so that you don't have to specify access
to each one, handy for super user accounts, etc.
So, like I said, I think there's a need for this out there, if anyone
likes it, or would like it more with some improvements or more thought,
let me know and I'll see what I can do about getting it cleaned up some
and onto CPAN.
Oh, and the name isn't set in stone, if anyone thinks something else
suits it better, speak-up.
--
Steve Comrie
LEAD SOFTWARE ARCHITECT | OCTANE
T: 416.977.2525
F: 416.977.8481
355 ADELAIDE ST. W. SUITE 1B
TORONTO, ONTARIO M5V 1S2
WWW.OCTANE.TO <http://www.octane.to>
