CGI-Application-Plugin-Authentication
view release on metacpan or search on metacpan
CGI::Application
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;
}
DESCRIPTION
CGI::Application::Plugin::Authentication adds the ability to
authenticate users in your 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).
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
CGI::Application::Plugin::Authentication::Driver::Generic,
CGI::Application::Plugin::Authentication::Driver::DBI and,
CGI::Application::Plugin::Authentication::Driver::Dummy docs for more
information on how to use these drivers. And see the Authen::Simple
suite of modules for information on those drivers.
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 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.
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.
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.
EXPORTED METHODS
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));
METHODS
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:
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'
],
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 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',
]
POST_LOGIN_RUNMODE
Here you can specify a runmode that the user will be redirected to
if they successfully login.
POST_LOGIN_RUNMODE => 'welcome'
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'
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);
...
}
LOGIN_RUNMODE
Here you can specify a runmode that the user will be redirected to
if they need to login.
LOGIN_RUNMODE => 'login'
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'
LOGOUT_RUNMODE
Here you can specify a runmode that the user will be redirected to
if they ask to logout.
LOGOUT_RUNMODE => 'logout'
LOGOUT_URL
If your logout 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 ask to logout. If both LOGOUT_URL and LOGOUT_RUNMODE are
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.
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\_]+)$
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' ]
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:
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.
EVERY
If this value is set, a re-authentication will be forced every x
amount of time.
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.
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;
}
}
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
}
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:
DISPLAY_CLASS (default: Classic)
the class used to display the login form. The alternative is
"Basic" which aims for XHTML compliance and leaving style to
CSS. See CGI::Application::Plugin::Authentication::Display for
more details.
TITLE (default: Sign In)
the heading at the top of the login box
USERNAME_LABEL (default: User Name)
the label for the user name input
PASSWORD_LABEL (default: Password)
( run in 0.453 second using v1.01-cache-2.11-cpan-d7f47b0818f )