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/exampl... 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@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