[dancer-users] Dancer::Plugin::Auth::Extensible - an authentication & access control framework for Dancer apps - RFC

[David Precious]

Hi all,

I've finally had time to hack further on the new Dancer
authentication / access control plugin I've been working on, and it's
at a state where I plan a beta CPAN release soon.

The module is Dancer::Plugin::Auth::Extensible, and can be found on
GitHub:

https://github.com/bigpresh/Dancer-Plugin-Auth-Extensible

I've written this as I tried to use D::P::Auth::RBAC, but I never
really got on with it, and IMO it needed a lot of work - so I decided
to write this from scratch.

The plan is to make user authentication and access control dead simple,
whilst also being extensible.

I'd very much appreciate comments and suggestions from anyone who has
time to look.

Just to give an idea how it works - you configure the plugin via the
app's config file (exactly what you put in depends on the
authentication provider you're using), then denote which routes require
authentication or specific roles using subroutine attributes - for
instance:

    get '/secrets' => sub RequiresLogin {
        tell_secrets();
    };

    get '/really-secret' => sub RequiresRole(BestFriend) {
        tell_everything();
    };

The first role could be accessed by anyone who is logged in; the second
can only be accessed by people with the specified role.  (If you only
need basic authentication and not roles, you can ignore the role
features; if you later need roles (e.g. you realise you need some users
with higher privileges than others) it's trivial to start using them.

The example app shipped with the module is a good place to look for a
simple example:

https://github.com/bigpresh/Dancer-Plugin-Auth-Extensible/tree/master/example

The framework is designed to to be flexible enough to use various
methods of authentication via the "provider" classes, and for new
providers to be easy to write.

All provider classes inherit from a base class which provides a
constructor, ensures the provider implements the required methods, and
provides a simple way to validate crypted passwords, so there is no
reason that passwords should be stored in plain text, ever.

So far, there is a "Config" provider which authenticates against
usernames and passwords in the app's config, a "Database" provider
which authenticates against a database (using the Database plugin), and
a "Unix" provider which authenticates against system accounts on a
*nix-type box.  A DBIx provider is coming soon, and others (such as
IMAP/LDAP) may well be provided too.

As the framework supports multiple realms, it's possible to configure
it to e.g. look in a database first, then try an IMAP server.

A basic login page, login handling code etc is provided automatically,
but can be overridden if desired.

I'm about to put this in to use myself; I'm hoping it will be of use to
other people, too.  So, please do let me know what you think, whether
it's of use to you, and whether there are any features that would make
it more useful to you!

I plan to tidy up the code a little and and improve the documentation
before a proper release, but it's in a position where I'm fairly happy
it works as it should, and already has a test suite of > 30 tests which
pass happily.

Cheers

Dave P


-- 
David Precious ("bigpresh") <davidp at preshweb.co.uk>
http://www.preshweb.co.uk/     www.preshweb.co.uk/twitter
www.preshweb.co.uk/linkedin    www.preshweb.co.uk/facebook
www.preshweb.co.uk/cpan        www.preshweb.co.uk/github