CGI-Application-Plugin-Authentication
view release on metacpan or search on metacpan
lib/CGI/Application/Plugin/Authentication.pm view on Meta::CPAN
CGI::Application::Plugin::Authentication - Authentication framework for CGI::Application
=head1 SYNOPSIS
package MyCGIApp;
use base qw(CGI::Application); # make sure this occurs before you load the plugin
use CGI::Application::Plugin::Authentication;
MyCGIApp->authen->config(
DRIVER => [ 'Generic', { user1 => '123' } ],
);
MyCGIApp->authen->protected_runmodes('myrunmode');
sub myrunmode {
my $self = shift;
# The user should be logged in if we got here
my $username = $self->authen->username;
}
=head1 DESCRIPTION
CGI::Application::Plugin::Authentication adds the ability to authenticate users
in your L<CGI::Application> modules. It imports one method called 'authen' into your
CGI::Application module. Through the authen method you can call all the methods of
the CGI::Application::Plugin::Authentication plugin.
There are two main decisions that you need to make when using this module. How will
the usernames and password be verified (i.e. from a database, LDAP, etc...), and how
can we keep the knowledge that a user has already logged in persistent, so that they
will not have to enter their credentials again on the next request (i.e. how do we 'Store'
the authentication information across requests).
=head2 Choosing a Driver
There are three drivers that are included with the distribution. Also, there
is built in support for all of the Authen::Simple modules (search CPAN for
Authen::Simple for more information). This should be enough to cover
everyone's needs.
If you need to authenticate against a source that is not provided, you can use
the Generic driver which will accept either a hash of username/password pairs,
or an array of arrays of credentials, or a subroutine reference that can verify
the credentials. So through the Generic driver you should be able to write
your own verification system. There is also a Dummy driver, which blindly
accepts any credentials (useful for testing). See the
L<CGI::Application::Plugin::Authentication::Driver::Generic>,
L<CGI::Application::Plugin::Authentication::Driver::DBI> and,
L<CGI::Application::Plugin::Authentication::Driver::Dummy> docs for more
information on how to use these drivers. And see the L<Authen::Simple> suite
of modules for information on those drivers.
=head2 Choosing a Store
The Store modules keep information about the authentication status of the user persistent
across multiple requests. The information that is stored in the store include the username,
and the expiry time of the login. There are two Store modules included with this distribution.
A Session based store, and a Cookie based store. If your application is already using
Sessions (through the L<CGI::Application::Plugin::Session> module), then I would recommend
that you use the Session store for authentication. If you are not using the Session
plugin, then you can use the Cookie store. The Cookie store keeps all the authentication
in a cookie, which contains a checksum to ensure that users can not change the information.
If you do not specify which Store module you wish to use, the plugin will try to determine
the best one for you.
=head2 Login page
The Authentication plugin comes with a default login page that can be used if you do not
want to create a custom login page. This login form will automatically be used if you
do not provide either a LOGIN_URL or LOGIN_RUNMODE parameter in the configuration.
If you plan to create your own login page, I would recommend that you start with the HTML
code for the default login page, so that your login page will contain the correct form
fields and hidden fields.
=head2 Ticket based authentication
This Authentication plugin can handle ticket based authentication systems as well. All that
is required of you is to write a Store module that can understand the contents of the ticket.
The Authentication plugin will require at least the 'username' to be retrieved from the
ticket. A Ticket based authentication scheme will not need a Driver module at all, since the
actual verification of credentials is done by an external authentication system, possibly
even on a different host. You will need to specify the location of the login page using
the LOGIN_URL configuration variable, and unauthenticated users will automatically
be redirected to your ticket authentication login page.
=head1 EXPORTED METHODS
=head2 authen
This is the only method exported from this module. Everything is controlled
through this method call, which will return a CGI::Application::Plugin::Authentication
object, or just the class name if called as a class method. When using
the plugin, you will always first call $self->authen or __PACKAGE__->authen and
then the method you wish to invoke. For example:
__PACKAGE__->authen->config(
LOGIN_RUNMODE => 'login',
);
- or -
$self->authen->protected_runmodes(qw(one two));
=cut
{ package # Hide from PAUSE
CGI::Application::Plugin::_::Authentication;
##############################################
###
### authen
###
##############################################
#
# Return an authen object that can be used
# for managing authentication.
#
# This will return a class name if called
lib/CGI/Application/Plugin/Authentication.pm view on Meta::CPAN
=head1 METHODS
=head2 config
This method is used to configure the CGI::Application::Plugin::Authentication
module. It can be called as an object method, or as a class method. Calling this function,
will not itself generate cookies or session ids.
The following parameters are accepted:
=over 4
=item DRIVER
Here you can choose which authentication module(s) you want to use to perform the authentication.
For simplicity, you can leave off the CGI::Application::Plugin::Authentication::Driver:: part
when specifying the DRIVER name If this module requires extra parameters, you
can pass an array reference that contains as the first parameter the name of the module,
and the rest of the values in the array will be considered options for the driver. You can provide
multiple drivers which will be used, in order, to check the credentials until
a valid response is received.
DRIVER => 'Dummy' # let anyone in regardless of the password
- or -
DRIVER => [ 'DBI',
DBH => $self->dbh,
TABLE => 'user',
CONSTRAINTS => {
'user.name' => '__CREDENTIAL_1__',
'MD5:user.password' => '__CREDENTIAL_2__'
},
],
- or -
DRIVER => [
[ 'Generic', { user1 => '123' } ],
[ 'Generic', sub { my ($u, $p) = @_; is_prime($p) ? 1 : 0 } ]
],
- or -
DRIVER => [ 'Authen::Simple::LDAP',
host => 'ldap.company.com',
basedn => 'ou=People,dc=company,dc=net'
],
=item STORE
Here you can choose how we store the authenticated information after a user has successfully
logged in. We need to store the username so that on the next request we can tell the user
has already logged in, and we do not have to present them with another login form. If you
do not provide the STORE option, then the plugin will look to see if you are using the
L<CGI::Application::Plugin::Session> module and based on that info use either the Session
module, or fall back on the Cookie module. If the module requires extra parameters, you
can pass an array reference that contains as the first parameter the name of the module,
and the rest of the array should contain key value pairs of options for this module.
These storage modules generally live under the CGI::Application::Plugin::Authentication::Store::
name-space, and this part of the package name can be left off when specifying the STORE
parameter.
STORE => 'Session'
- or -
STORE => ['Cookie',
NAME => 'MYAuthCookie',
SECRET => 'FortyTwo',
EXPIRY => '1d',
]
=item POST_LOGIN_RUNMODE
Here you can specify a runmode that the user will be redirected to if they successfully login.
POST_LOGIN_RUNMODE => 'welcome'
=item POST_LOGIN_URL
Here you can specify a URL that the user will be redirected to if they successfully login.
If both POST_LOGIN_URL and POST_LOGIN_RUNMODE are specified, then the latter
will take precedence.
POST_LOGIN_URL => 'http://example.com/start.cgi'
=item POST_LOGIN_CALLBACK
A code reference that is executed after login processing but before POST_LOGIN_RUNMODE or
redirecting to POST_LOGIN_URL. This is normally a method in your CGI::Application application
and as such the CGI::Application object is passed as a parameter.
POST_LOGIN_CALLBACK => \&update_login_date
and later in your code:
sub update_login_date {
my $self = shift;
return unless($self->authen->is_authenticated);
...
}
=item LOGIN_RUNMODE
Here you can specify a runmode that the user will be redirected to if they need to login.
LOGIN_RUNMODE => 'login'
=item LOGIN_URL
If your login page is external to this module, then you can use this option to specify a
URL that the user will be redirected to when they need to login. If both
LOGIN_URL and LOGIN_RUNMODE are specified, then the latter will take precedence.
LOGIN_URL => 'http://example.com/login.cgi'
=item LOGOUT_RUNMODE
Here you can specify a runmode that the user will be redirected to if they ask to logout.
LOGOUT_RUNMODE => 'logout'
=item LOGOUT_URL
lib/CGI/Application/Plugin/Authentication.pm view on Meta::CPAN
^([\w\_\%\?\&\;\-\/\@\.\+\$\=\#\:\!\*\"\'\(\)\,]+)$
This regular expression is based upon the document http://www.w3.org/Addressing/URL/url-spec.txt. You could
set it to a more specific regular expression to limit the domains to which users could be directed.
=item DETAINT_USERNAME_REGEXP
This is a regular expression used to detaint the username parameter used in the login form. By default it will be set to
^([\w\_]+)$
=item CREDENTIALS
Set this to the list of form fields where the user will type in their username and password.
By default this is set to ['authen_username', 'authen_password']. The form field names should
be set to a value that you are not likely to use in any other forms. This is important
because this plugin will automatically look for query parameters that match these values on
every request to see if a user is trying to log in. So if you use the same parameter names
on a user management page, you may inadvertently perform a login when that was not intended.
Most of the Driver modules will return the first CREDENTIAL as the username, so make sure
that you list the username field first. This option can be ignored if you use the built in
login box
CREDENTIALS => 'authen_password'
- or -
CREDENTIALS => [ 'authen_username', 'authen_domain', 'authen_password' ]
=item LOGIN_SESSION_TIMEOUT
This option can be used to tell the system when to force the user to re-authenticate. There are
a few different possibilities that can all be used concurrently:
=over 4
=item IDLE_FOR
If this value is set, a re-authentication will be forced if the user was idle for more then x amount of time.
=item EVERY
If this value is set, a re-authentication will be forced every x amount of time.
=item CUSTOM
This value can be set to a subroutine reference that returns true if the session should be timed out,
and false if it is still active. This can allow you to be very selective about how the timeout system
works. The authen object will be passed in as the only parameter.
=back
Time values are specified in seconds. You can also specify the time by using a number with the
following suffixes (m h d w), which represent minutes, hours, days and weeks. The default
is 0 which means the login will never timeout.
Note that the login is also dependent on the type of STORE that is used. If the Session store is used,
and the session expires, then the login will also automatically expire. The same goes for the Cookie
store.
For backwards compatibility, if you set LOGIN_SESSION_TIMEOUT to a time value instead of a hashref,
it will be treated as an IDLE_FOR time out.
# force re-authentication if idle for more than 15 minutes
LOGIN_SESSION_TIMEOUT => '15m'
# Everyone must re-authentication if idle for more than 30 minutes
# also, everyone must re-authentication at least once a day
# and root must re-authentication if idle for more than 5 minutes
LOGIN_SESSION_TIMEOUT => {
IDLE_FOR => '30m',
EVERY => '1d',
CUSTOM => sub {
my $authen = shift;
return ($authen->username eq 'root' && (time() - $authen->last_access) > 300) ? 1 : 0;
}
}
=item RENDER_LOGIN
This value can be set to a subroutine reference that returns the HTML of a login
form. The subroutine reference overrides the default call to login_box.
The subroutine is normally a method in your CGI::Application application and as such the
CGI::Application object is passed as the first parameter.
RENDER_LOGIN => \&login_form
and later in your code:
sub login_form {
my $self = shift;
...
return $html
}
=item LOGIN_FORM
You can set this option to customize the login form that is created when a user
needs to be authenticated. If you wish to replace the entire login form with a
completely custom version, then just set LOGIN_RUNMODE to point to your custom
runmode.
All of the parameters listed below are optional, and a reasonable default will
be used if left blank:
=over 4
=item DISPLAY_CLASS (default: Classic)
the class used to display the login form. The alternative is C<Basic>
which aims for XHTML compliance and leaving style to CSS. See
L<CGI::Application::Plugin::Authentication::Display> for more details.
=item TITLE (default: Sign In)
the heading at the top of the login box
lib/CGI/Application/Plugin/Authentication.pm view on Meta::CPAN
verifying the login credentials. Calling this function, will not itself generate cookies or session ids.
=cut
sub drivers {
my $self = shift;
if ( !$self->{drivers} ) {
my $config = $self->_config;
# Fetch the configuration parameters for the driver(s)
my $driver_configs = defined $config->{DRIVER} ? $config->{DRIVER} : [['Dummy']];
foreach my $driver_config (@$driver_configs) {
my ($drivername, @params) = @$driver_config;
# add support for Authen::Simple modules
if (index($drivername, 'Authen::Simple') == 0) {
unshift @params, $drivername;
$drivername = 'Authen::Simple';
}
# Load the the class for this driver
my $driver_class = _find_deligate_class(
'CGI::Application::Plugin::Authentication::Driver::' . $drivername,
$drivername
) || die "Driver ".$drivername." can not be found";
# Create the driver object
my $driver = $driver_class->new( $self, @params )
|| die "Could not create new $driver_class object";
push @{$self->{drivers}}, $driver;
}
}
my $drivers = $self->{drivers};
return @$drivers[0..$#$drivers];
}
=head2 store
This method will return a store object that is used to store information
about the status of the authentication across multiple requests.
This function will initiate a session or cookie if one has not been created already.
=cut
sub store {
my $self = shift;
if ( !$self->{store} ) {
my $config = $self->_config;
# Fetch the configuration parameters for the store
my ($store_module, @store_config);
($store_module, @store_config) = @{ $config->{STORE} } if $config->{STORE} && ref $config->{STORE} eq 'ARRAY';
if (!$store_module) {
# No STORE configuration was provided
if ($self->_cgiapp->can('session') && UNIVERSAL::isa($self->_cgiapp->session, 'CGI::Session')) {
# The user is already using the Session plugin
($store_module, @store_config) = ( 'Session' );
} else {
# Fall back to the Cookie Store
($store_module, @store_config) = ( 'Cookie' );
}
}
# Load the the class for this store
my $store_class = _find_deligate_class(
'CGI::Application::Plugin::Authentication::Store::' . $store_module,
$store_module
) || die "Store $store_module can not be found";
# Create the store object
$self->{store} = $store_class->new( $self, @store_config )
|| die "Could not create new $store_class object";
}
return $self->{store};
}
=head2 initialize
This does most of the heavy lifting for the Authentication plugin. It will
check to see if the user is currently attempting to login by looking for the
credential form fields in the query object. It will load the required driver
objects and authenticate the user. It is OK to call this method multiple times
as it checks to see if it has already been executed and will just return
without doing anything if called multiple times. This allows us to call
initialize as late as possible in the request so that no unnecessary work is
done.
The user will be logged out by calling the C<logout()> method if the login
session has been idle for too long, if it has been too long since the last
login, or if the login has timed out. If you need to know if a user was logged
out because of a time out, you can call the C<is_login_timeout> method.
If all goes well, a true value will be returned, although it is usually not
necessary to check.
This function will initiate a session or cookie if one has not been created already.
=cut
sub initialize {
my $self = shift;
return 1 if $self->{initialized};
# It would seem to make more sense to do this at the /end/ of the routine
# but that causes an infinite loop.
$self->{initialized} = 1;
if (UNIVERSAL::can($self->_cgiapp, 'devpopup')) {
$self->_cgiapp->add_callback( 'devpopup_report', \&_devpopup_report );
}
my $config = $self->_config;
# See if the user is trying to log in
# We do this before checking to see if the user is already logged in, since
# a logged in user may want to log in as a different user.
my $field_names = $config->{CREDENTIALS} || [qw(authen_username authen_password)];
my $query = $self->_cgiapp->query;
( run in 0.455 second using v1.01-cache-2.11-cpan-d7f47b0818f )