CGI::Compress::Gzip extends the CGI class to auto-detect whether the
client browser wants compressed output and apply gzip compression on any
content printed on the default filehandle. This module is intended to
be a drop-in replacement for CGI.pm in a typical scripting environment.
CGI::Session::ExpireSessions is a pure Perl module.
It deletes CGI::Session-type sessions which have passed their use-by date.
It works with CGI::Session-type sessions in a database or in disk files,
but does not appear to work with CGI::Session::PureSQL-type sessions.
The recommended way to use this module is via method expire_sessions(),
which requires CGI::Session V 4 or later.
This Input Handler verifies that it is dealing with a reasonable date.
Reasonably means anything that Date::Manip thinks is sensible, so you
could use any of (for example): "December 12, 2001" "12th December, 2001"
"2001-12-12" "next Tuesday" "third Wednesday in March"
See Date::Manip for much more information on what date formats are
acceptable.
The resulting date will be a Date::Simple object. Date::Simple for more
information on this.
CGI::Untaint::email input handler verifies that it is a
valid RFC2822 mailbox format.
The resulting value will be a Mail::Address instance.
This action implements a sensible default end action, which will forward
to the first available view, unless status is set to 3xx, or there is a
response body. It also allows you to pass "dump_info=1" to the url in
order to force a debug screen, while in debug mode.
If you have more than one view, you can specify which one to use with
the "default_view" config setting (see ""$c->view($name)" in "Catalyst".)
Provides a Catalyst reusable action role for user role-based authorization.
ACLs are applied via the assignment of attributes to application action
subroutines.
OpenID credential for Catalyst::Plugin::Authentication framework.
A storage class for Catalyst Authentication using DBIx::Class
This plugin implements the Catalyst::Authentication v.10 API.
This plugin uses Net::LDAP to let your application authenticate against
an LDAP directory. It has a pretty high degree of flexibility, given
the wide variation of LDAP directories and schemas from one system to
another.
It authenticates users in two steps:
1) A search of the directory is performed, looking for a user object
that matches the username you pass. This is done with the bind
credentials supplied in the "binddn" and "bindpw" configuration options.
2) If that object is found, we then re-bind to the directory as that
object. Assuming this is successful, the user is Authenticated.