=head1 NAME
-Catalyst::Manual::Tutorial::Authentication - Catalyst Tutorial - Part 5: Authentication
+Catalyst::Manual::Tutorial::Authentication - Catalyst Tutorial - Chapter 5: Authentication
=head1 OVERVIEW
-This is B<Part 5 of 10> for the Catalyst tutorial.
+This is B<Chapter 5 of 10> for the Catalyst tutorial.
L<Tutorial Overview|Catalyst::Manual::Tutorial>
=head1 DESCRIPTION
-Now that we finally have a simple yet functional application, we can
-focus on providing authentication (with authorization coming next in
-Part 6).
+Now that we finally have a simple yet functional application, we can
+focus on providing authentication (with authorization coming next in
+Chapter 6).
-This part of the tutorial is divided into two main sections: 1) basic,
+This chapter of the tutorial is divided into two main sections: 1) basic,
cleartext authentication and 2) hash-based authentication.
You can checkout the source code for this example from the catalyst
subversion repository as per the instructions in
-L<Catalyst::Manual::Tutorial::Intro>
+L<Catalyst::Manual::Tutorial::Intro|Catalyst::Manual::Tutorial::Intro>.
+
=head1 BASIC AUTHENTICATION
First, we add both user and role information to the database (we will
add the role information here although it will not be used until the
-authorization section, Part 6). Create a new SQL script file by opening
+authorization section, Chapter 6). Create a new SQL script file by opening
C<myapp02.sql> in your editor and insert:
--
the new tables added in the previous step, let's use the C<create=static>
option on the DBIC model helper to do most of the work for us:
- $ script/myapp_create.pl model DB DBIC::Schema MyApp::Schema create=static dbi:SQLite:myapp.db
- $ ls lib/MyApp/Schema
+ $ script/myapp_create.pl model DB DBIC::Schema MyApp::Schema \
+ create=static components=TimeStamp dbi:SQLite:myapp.db
+ exists "/root/dev/MyApp/script/../lib/MyApp/Model"
+ exists "/root/dev/MyApp/script/../t"
+ Dumping manual schema for MyApp::Schema to directory /root/dev/MyApp/script/../lib ...
+ Schema dump completed.
+ exists "/root/dev/MyApp/script/../lib/MyApp/Model/DB.pm"
+ $
+ $ ls lib/MyApp/Schema/Result
Authors.pm BookAuthors.pm Books.pm Roles.pm UserRoles.pm Users.pm
-Notice how the helper has added three new table-specific result source
-files to the C<lib/MyApp/Schema/MyApp> directory. And, more
-importantly, even if there were changes to the existing result source
-files, those changes would have only been written above the C<# DO NOT
-MODIFY THIS OR ANYTHING ABOVE!> comment and your hand-editted
+Notice how the helper has added three new table-specific result source
+files to the C<lib/MyApp/Schema/Result> directory. And, more
+importantly, even if there were changes to the existing result source
+files, those changes would have only been written above the C<# DO NOT
+MODIFY THIS OR ANYTHING ABOVE!> comment and your hand-edited
enhancements would have been preserved.
-
-Speaking of "hand-editted enhancements," we should now add
-relationship information to the three new result source files. Edit
-each of these files and add the following information between the C<#
+Speaking of "hand-edit ted enhancements," we should now add
+relationship information to the three new result source files. Edit
+each of these files and add the following information between the C<#
DO NOT MODIFY THIS OR ANYTHING ABOVE!> comment and the closing C<1;>:
-C<lib/MyApp/Schema/Users.pm>:
+C<lib/MyApp/Schema/Result/Users.pm>:
#
# Set relationships:
# args:
# 1) Name of relationship, DBIC will create accessor with this name
# 2) Name of the model class referenced by this relationship
- # 3) Column name in *foreign* table
- __PACKAGE__->has_many(map_user_role => 'MyApp::Schema::UserRoles', 'user_id');
+ # 3) Column name in *foreign* table (aka, foreign key in peer table)
+ __PACKAGE__->has_many(map_user_role => 'MyApp::Schema::Result::UserRoles', 'user_id');
# many_to_many():
# args:
# 1) Name of relationship, DBIC will create accessor with this name
- # 2) Name of has_many() relationship this many_to_many() is shortcut for
- # 3) Name of belongs_to() relationship in model class of has_many() above
+ # 2) Name of has_many() relationship this many_to_many() is shortcut for
+ # 3) Name of belongs_to() relationship in model class of has_many() above
# You must already have the has_many() defined to use a many_to_many().
__PACKAGE__->many_to_many(roles => 'map_user_role', 'role');
-C<lib/MyApp/Schema/Roles.pm>:
+C<lib/MyApp/Schema/Result/Roles.pm>:
#
# Set relationships:
# args:
# 1) Name of relationship, DBIC will create accessor with this name
# 2) Name of the model class referenced by this relationship
- # 3) Column name in *foreign* table
- __PACKAGE__->has_many(map_user_role => 'MyApp::Schema::UserRoles', 'role_id');
+ # 3) Column name in *foreign* table (aka, foreign key in peer table)
+ __PACKAGE__->has_many(map_user_role => 'MyApp::Schema::Result::UserRoles', 'role_id');
-C<lib/MyApp/Schema/UserRoles.pm>:
+C<lib/MyApp/Schema/Result/UserRoles.pm>:
#
# Set relationships:
# 1) Name of relationship, DBIC will create accessor with this name
# 2) Name of the model class referenced by this relationship
# 3) Column name in *this* table
- __PACKAGE__->belongs_to(user => 'MyApp::Schema::Users', 'user_id');
+ __PACKAGE__->belongs_to(user => 'MyApp::Schema::Result::Users', 'user_id');
# belongs_to():
# args:
# 1) Name of relationship, DBIC will create accessor with this name
# 2) Name of the model class referenced by this relationship
# 3) Column name in *this* table
- __PACKAGE__->belongs_to(role => 'MyApp::Schema::Roles', 'role_id');
+ __PACKAGE__->belongs_to(role => 'MyApp::Schema::Result::Roles', 'role_id');
-The code for these three sets of updates is obviously very similar to
-the edits we made to the C<Books>, C<Authors>, and C<BookAuthors>
-classes created in Part 3.
+The code for these three sets of updates is obviously very similar to
+the edits we made to the C<Books>, C<Authors>, and C<BookAuthors>
+classes created in Chapter 3.
-Note that we do not need to make any change to the
-C<lib/MyApp/Schema.pm> schema file. It simple tells DBIC to
-load all of the result source files it finds in below the
-C<lib/MyApp/Schema> directory, so it will automatically pick
-up our new table information.
+Note that we do not need to make any change to the
+C<lib/MyApp/Schema.pm> schema file. It simply tells DBIC to load all
+of the Result Class and ResultSet Class files it finds in below the
+C<lib/MyApp/Schema> directory, so it will automatically pick up our
+new table information.
=head2 Sanity-Check Reload of Development Server
-We aren't ready to try out the authentication just yet; we only want
-to do a quick check to be sure our model loads correctly. Press
-C<Ctrl-C> to kill the previous server instance (if it's still running)
+We aren't ready to try out the authentication just yet; we only want
+to do a quick check to be sure our model loads correctly. Press
+C<Ctrl-C> to kill the previous server instance (if it's still running)
and restart it:
$ script/myapp_server.pl
'-------------------------------------------------------------------+----------'
...
-Again, notice that your "result source" classes have been "re-loaded"
+Again, notice that your "Result Class" classes have been "re-loaded"
by Catalyst under C<MyApp::Model>.
=head2 Include Authentication and Session Plugins
-Edit C<lib/MyApp.pm> and update it as follows (everything below
+Edit C<lib/MyApp.pm> and update it as follows (everything below
C<StackTrace> is new):
- use Catalyst qw/
- -Debug
- ConfigLoader
- Static::Simple
-
- StackTrace
-
- Authentication
-
- Session
- Session::Store::FastMmap
- Session::State::Cookie
- /;
-
-The C<Authentication> plugin supports Authentication while the
-C<Session> plugins are required to maintain state across multiple HTTP
-requests.
-
-Note that the only required Authentication class is the main one. This
-is a change that occurred in version 0.09999_01 of the
-C<Authentication> plugin. You B<do not need> to specify a particular
-Authentication::Store or Authentication::Credential plugin. Instead,
-indicate the Store and Credential you want to use in your application
+ # Load plugins
+ use Catalyst qw/-Debug
+ ConfigLoader
+ Static::Simple
+
+ StackTrace
+
+ Authentication
+
+ Session
+ Session::Store::FastMmap
+ Session::State::Cookie
+ /;
+
+B<Note:> As discussed in MoreCatalystBasics, different versions of
+C<Catalyst::Devel> have used a variety of methods to load the plugins.
+You can put the plugins in the C<use Catalyst> statement if you prefer.
+
+The C<Authentication> plugin supports Authentication while the
+C<Session> plugins are required to maintain state across multiple HTTP
+requests.
+
+Note that the only required Authentication class is the main one. This
+is a change that occurred in version 0.09999_01 of the
+C<Authentication> plugin. You B<do not need> to specify a particular
+Authentication::Store or Authentication::Credential plugin. Instead,
+indicate the Store and Credential you want to use in your application
configuration (see below).
-Note that there are several options for
-L<Session::Store|Catalyst::Plugin::Session::Store>
-(L<Session::Store::FastMmap|Catalyst::Plugin::Session::Store::FastMmap>
-is generally a good choice if you are on Unix; try
-L<Session::Store::File|Catalyst::Plugin::Session::Store::File> if you
-are on Win32) -- consult
-L<Session::Store|Catalyst::Plugin::Session::Store> and its subclasses
+Note that there are several options for
+L<Session::Store|Catalyst::Plugin::Session::Store>
+(L<Session::Store::FastMmap|Catalyst::Plugin::Session::Store::FastMmap>
+is generally a good choice if you are on Unix; try
+L<Session::Store::File|Catalyst::Plugin::Session::Store::File> if you
+are on Win32) -- consult
+L<Session::Store|Catalyst::Plugin::Session::Store> and its subclasses
for additional information and options (for example to use a database-
backed session store).
=head2 Configure Authentication
-Although C<__PACKAGE__-E<gt>config(name =E<gt> 'value');> is still
-supported, newer Catalyst applications tend to place all configuration
-information in C<myapp.conf> and automatically load this information
-into C<MyApp-E<gt>config> using the
-L<ConfigLoader|Catalyst::Plugin::ConfigLoader> plugin.
-
-First, as noted in Part 3 of the tutorial, Catalyst has recently
-switched from a default config file format of YAML to
-C<Config::General> (an apache-like format). In case you are using
-a version of Catalyst earlier than v5.7014, delete the C<myapp.yml>
-file and simply follow the directions below to create a new
-C<myapp.conf> file.
-
-Here, we need to load several parameters that tell
-L<Catalyst::Plugin::Authentication|Catalyst::Plugin::Authentication>
-where to locate information in your database. To do this, edit the
-C<myapp.conf> file and update it to match:
-
- name MyApp
- <authentication>
- default_realm dbic
- <realms>
- <dbic>
- <credential>
- # Note this first definition would be the same as setting
- # __PACKAGE__->config->{authentication}->{realms}->{dbic}
- # ->{credential} = 'Password' in lib/MyApp.pm
- #
- # Specify that we are going to do password-based auth
- class Password
- # This is the name of the field in the users table with the
- # password stored in it
- password_field password
- # We are using an unencrypted password now
- password_type clear
- </credential>
- <store>
- # Use DBIC to retrieve username, password & role information
- class DBIx::Class
- # This is the model object created by Catalyst::Model::DBIC
- # from your schema (you created 'MyApp::Schema::User' but as
- # the Catalyst startup debug messages show, it was loaded as
- # 'MyApp::Model::DB::Users').
- # NOTE: Omit 'MyApp::Model' here just as you would when using
- # '$c->model("DB::Users)'
- user_class DB::Users
- # This is the name of the field in your 'users' table that
- # contains the user's name
- id_field username
- </store>
- </dbic>
- </realms>
- </authentication>
-
-Inline comments in the code above explain how each field is being used.
-
-Note that you can use many other config file formats with catalyst.
-See L<Catalyst::Plugin::ConfigLoader|Catalyst::Plugin::ConfigLoader>
-for details.
+There are a variety of way to provide configuration information to
+L<Catalyst::Plugin::Authentication|Catalyst::Plugin::Authentication>.
+Here we will use
+L<Catalyst::Authentication::Realm::SimpleDB|Catalyst::Authentication::Realm::SimpleDB>
+because it automatically sets a reasonable set of defaults for us. Open
+C<lib/MyApp.pm> and place the following text above the call to
+C<__PACKAGE__-E<gt>setup();>:
+
+ # Configure SimpleDB Authentication
+ __PACKAGE__->config->{'Plugin::Authentication'} = {
+ default => {
+ class => 'SimpleDB',
+ user_model => 'DB::Users',
+ password_type => 'clear',
+ },
+ };
+
+We could have placed this configuration in C<myapp.conf>, but placing
+it in C<lib/MyApp.pm> is probably a better place since it's not likely
+something that users of your application will want to change during
+deployment.
+
=head2 Add Login and Logout Controllers
$ script/myapp_create.pl controller Login
$ script/myapp_create.pl controller Logout
-B<NOTE:> You could easily use a single controller here. For example,
-you could have a C<User> controller with both C<login> and C<logout>
-actions. Remember, Catalyst is designed to be very flexible, and leaves
-such matters up to you, the designer and programmer.
-
-Then open C<lib/MyApp/Controller/Login.pm>, locate the C<sub index
-:Path :Args(0)> method (or C<sub index : Private> if you are using an
-older version of Catalyst) that was automatically inserted by the
-helpers when we created the Login controller above, and delete this
-line:
+You could easily use a single controller here. For example, you could
+have a C<User> controller with both C<login> and C<logout> actions.
+Remember, Catalyst is designed to be very flexible, and leaves such
+matters up to you, the designer and programmer.
- $c->response->body('Matched MyApp::Controller::Login in Login.');
-
-Then update it to match:
+Then open C<lib/MyApp/Controller/Login.pm>, locate the
+C<sub index :Path :Args(0)> method (or C<sub index : Private> if you
+are using an older version of Catalyst) that was automatically
+inserted by the helpers when we created the Login controller above,
+and update the definition of C<sub index> to match:
=head2 index
# If the username and password values were found in form
if ($username && $password) {
# Attempt to log the user in
- if ($c->authenticate({ username => $username,
- password => $password} )) {
+ if ($c->authenticate({ username => $username,
+ password => $password } )) {
# If successful, then let them use the application
- $c->response->redirect($c->uri_for('/books/list'));
+ $c->response->redirect($c->uri_for(
+ $c->controller('Books')->action_for('list')));
return;
} else {
# Set an error message
}
This controller fetches the C<username> and C<password> values from the
-login form and attempts to authenticate the user. If successful, it
-redirects the user to the book list page. If the login fails, the user
-will stay at the login page but receive an error message. If the
-C<username> and C<password> values are not present in the form, the
+login form and attempts to authenticate the user. If successful, it
+redirects the user to the book list page. If the login fails, the user
+will stay at the login page and receive an error message. If the
+C<username> and C<password> values are not present in the form, the
user will be taken to the empty login form.
-Note that we could have used something like C<sub default :Path>,
-however partly for historical reasons, and partly for code clarity it
-is generally recommended only to use C<default> in
+Note that we could have used something like "C<sub default :Path>",
+however, it is generally recommended (partly for historical reasons,
+and partly for code clarity) only to use C<default> in
C<MyApp::Controller::Root>, and then mainly to generate the 404 not
found page for the application.
-Instead, we are using C<sub base :Path :Args(0) {...}> here to
-specifically match the URL C</login>. C<Path> actions (aka, "literal
-actions") create URI matches relative to the namespace of the
-controller where they are defined. Although C<Path> supports
-arguments that allow relative and absolute paths to be defined, here
-we use an empty C<Path> definition to match on just the name of the
-controller itself. The method name, C<index>, is arbitrary. We make
+Instead, we are using "C<sub somename :Path :Args(0) {...}>" here to
+specifically match the URL C</login>. C<Path> actions (aka, "literal
+actions") create URI matches relative to the namespace of the
+controller where they are defined. Although C<Path> supports
+arguments that allow relative and absolute paths to be defined, here
+we use an empty C<Path> definition to match on just the name of the
+controller itself. The method name, C<index>, is arbitrary. We make
the match even more specific with the C<:Args(0)> action modifier --
-this forces the match on I<only> C</login>, not
+this forces the match on I<only> C</login>, not
C</login/somethingelse>.
-Next, update the corresponding method in
+Next, update the corresponding method in
C<lib/MyApp/Controller/Logout.pm> to match:
=head2 index
$c->response->redirect($c->uri_for('/'));
}
-As with the login controller, be sure to delete the
+As with the login controller, be sure to delete the
C<$c-E<gt>response-E<gt>body('Matched MyApp::Controller::Logout in Logout.');>
line of the C<sub index>.
[% META title = 'Login' %]
<!-- Login form -->
- <form method="post" action=" [% Catalyst.uri_for('/login') %] ">
+ <form method="post" action="[% c.uri_for('/login') %]">
<table>
<tr>
<td>Username:</td>
=cut
# Note that 'auto' runs after 'begin' but before your actions and that
- # 'auto' "chain" (all from application path to most specific class are run)
+ # 'auto's "chain" (all from application path to most specific class are run)
# See the 'Actions' section of 'Catalyst::Manual::Intro' for more info.
sub auto : Private {
my ($self, $c) = @_;
# Allow unauthenticated users to reach the login page. This
- # allows anauthenticated users to reach any action in the Login
+ # allows unauthenticated users to reach any action in the Login
# controller. To lock it down to a single action, we could use:
# if ($c->action eq $c->controller('Login')->action_for('index'))
- # to only allow unauthenticated access to the C<index> action we
+ # to only allow unauthenticated access to the 'index' action we
# added above.
if ($c->controller eq $c->controller('Login')) {
return 1;
return 1;
}
-
-B<Note:> Catalyst provides a number of different types of actions,
-such as C<Local>, C<Regex>, C<Private> and the new C<Path>. You
-should refer to L<Catalyst::Manual::Intro|Catalyst::Manual::Intro> for
-a more detailed explanation, but the following bullet points provide a
-quick introduction:
-
-=over 4
-
-=item *
-
-The majority of application have traditionally use C<Local> actions
-for items that respond to user requests and C<Private> actions for
-those that do not directly respond to user input.
-
-=item *
-
-Newer Catalyst applications tend to use C<Path> actions and the
-C<Args> attribute because of their power and flexibility. You can
-specify the path to match relative to the namespace of the current
-module as an argument to C<Path>. For example C<Path('list')> in
-C<lib/MyApp/Controller/Books.pm> would match on the URL
-C<http://localhost:3000/books/list> but C<Path('/list')> would
-match on C<http://localhost:3000/list>.
-
-=item *
-
-Automatic "chaining" of actions by the dispatcher is a powerful
-feature that allows multiple methods to handle a single URL. See
-L<Catalyst::DispatchType::Chained|Catalyst::DispatchType::Chained>
-for more information on chained actions.
-
-=item *
-
-There are five types of build-in C<Private> actions: C<begin>, C<end>,
-C<default>, C<index>, and C<auto>.
-
-=item *
-
-With C<begin>, C<end>, C<default>, C<index> private actions, only the
-most specific action of each type will be called. For example, if you
-define a C<begin> action in your controller it will I<override> a
-C<begin> action in your application/root controller -- I<only> the
-action in your controller will be called.
-
-=item *
-
-Unlike the other actions where only a single method is called for each
-request, I<every> auto action along the chain of namespaces will be
-called. Each C<auto> action will be called I<from the application/root
-controller down through the most specific class>.
-
-=back
-
-By placing the authentication enforcement code inside the C<auto> method
-of C<lib/MyApp/Controller/Root.pm> (or C<lib/MyApp.pm>), it will be
-called for I<every> request that is received by the entire application.
+As discussed in
+L<Catalyst::Manual::Tutorial::MoreCatalystBasics/CREATE A CATALYST CONTROLLER>,
+every C<auto> method from the application/root controller down to the
+most specific controller will be called. By placing the
+authentication enforcement code inside the C<auto> method of
+C<lib/MyApp/Controller/Root.pm> (or C<lib/MyApp.pm>), it will be
+called for I<every> request that is received by the entire
+application.
=head2 Displaying Content Only to Authenticated Users
this, open C<root/src/login.tt2> in your editor and add the following
lines to the bottom of the file:
+ ...
<p>
[%
- # This code illustrates how certain parts of the TT
+ # This code illustrates how certain parts of the TT
# template will only be shown to users who have logged in
%]
- [% IF Catalyst.user_exists %]
- Please Note: You are already logged in as '[% Catalyst.user.username %]'.
- You can <a href="[% Catalyst.uri_for('/logout') %]">logout</a> here.
+ [% IF c.user_exists %]
+ Please Note: You are already logged in as '[% c.user.username %]'.
+ You can <a href="[% c.uri_for('/logout') %]">logout</a> here.
[% ELSE %]
You need to log in to use this application.
[% END %]
[%#
Note that this whole block is a comment because the "#" appears
- immediate after the "[%" (with no spaces in between). Although it
- can be a handy way to temporarily "comment out" a whole block of
- TT code, it's probably a little too subtle for use in "normal"
+ immediate after the "[%" (with no spaces in between). Although it
+ can be a handy way to temporarily "comment out" a whole block of
+ TT code, it's probably a little too subtle for use in "normal"
comments.
%]
</p>
$ script/myapp_server.pl
-B<IMPORTANT NOTE:> If you are having issues with authentication on
-Internet Explorer, be sure to check the system clocks on both your
-server and client machines. Internet Explorer is very picky about
-timestamps for cookies. Note that you can quickly sync an Ubuntu
-system with the following command:
+B<IMPORTANT NOTE:> If you are having issues with authentication on
+Internet Explorer, be sure to check the system clocks on both your
+server and client machines. Internet Explorer is very picky about
+timestamps for cookies. You can quickly sync a Debian system by
+installing the "ntpdate" package:
- sudo ntpdate ntp.ubuntu.com
+ sudo aptitude -y install ntpdate
+
+And then run the following command:
+
+ sudo ntpdate-debian
+
+Or, depending on your firewall configuration:
+
+ sudo ntpdate-debian -u
+
+Note: NTP can be a little more finicky about firewalls because it uses
+UDP vs. the more common TCP that you see with most Internet protocols.
+Worse case, you might have to manually set the time on your development
+box instead of using NTP.
Now trying going to L<http://localhost:3000/books/list> and you should
-be redirected to the login page, hitting Shift+Reload if necessary (the
-"You are already logged in" message should I<not> appear -- if it does,
-click the C<logout> button and try again). Note the C<***Root::auto User
-not found...> debug message in the development server output. Enter
-username C<test01> and password C<mypass>, and you should be taken to
-the Book List page.
+be redirected to the login page, hitting Shift+Reload or Ctrl+Reload
+if necessary (the "You are already logged in" message should I<not>
+appear -- if it does, click the C<logout> button and try again). Note
+the C<***Root::auto User not found...> debug message in the
+development server output. Enter username C<test01> and password
+C<mypass>, and you should be taken to the Book List page.
Open C<root/src/books/list.tt2> and add the following lines to the
bottom (below the closing </table> tag):
<p>
- <a href="[% Catalyst.uri_for('/login') %]">Login</a>
- <a href="[% Catalyst.uri_for('form_create') %]">Create</a>
+ <a href="[% c.uri_for('/login') %]">Login</a>
+ <a href="[% c.uri_for(c.controller.action_for('form_create')) %]">Create</a>
</p>
-Reload your browser and you should now see a "Login" and "Create" links
-at the bottom of the page (as mentioned earlier, you can update template
-files without reloading the development server). Click the first link
-to return to the login page. This time you I<should> see the "You are
+Reload your browser and you should now see a "Login" and "Create" links
+at the bottom of the page (as mentioned earlier, you can update template
+files without reloading the development server). Click the first link
+to return to the login page. This time you I<should> see the "You are
already logged in" message.
Finally, click the C<You can logout here> link on the C</login> page.
=head1 USING PASSWORD HASHES
-In this section we increase the security of our system by converting
-from cleartext passwords to SHA-1 password hashes.
+In this section we increase the security of our system by converting
+from cleartext passwords to SHA-1 password hashes that include a
+random "salt" value to make them extremely difficult to crack with
+dictionary and "rainbow table" attacks.
B<Note:> This section is optional. You can skip it and the rest of the
tutorial will function normally.
-Note that even with the techniques shown in this section, the browser
+Be aware that even with the techniques shown in this section, the browser
still transmits the passwords in cleartext to your application. We are
just avoiding the I<storage> of cleartext passwords in the database by
-using a SHA-1 hash. If you are concerned about cleartext passwords
+using a salted SHA-1 hash. If you are concerned about cleartext passwords
between the browser and your application, consider using SSL/TLS, made
easy with the Catalyst plugin Catalyst::Plugin:RequireSSL.
-=head2 Get a SHA-1 Hash for the Password
+=head2 Install DBIx::Class::EncodedColumn
-Catalyst uses the C<Digest> module to support a variety of hashing
-algorithms. Here we will use SHA-1 (SHA = Secure Hash Algorithm).
-First, we should compute the SHA-1 hash for the "mypass" password we are
-using. The following command-line Perl script provides a "quick and
-dirty" way to do this:
+L<DBIx::Class::EncodedColumn|DBIx::Class::EncodedColumn> provides features
+that can greatly simplify the maintenance of passwords. It's currently
+not available as a .deb package in the normal Debian repositories, so let's
+install it directly from CPAN:
- $ perl -MDigest::SHA -e 'print Digest::SHA::sha1_hex("mypass"), "\n"'
- e727d1464ae12436e899a726da5b2f11d8381b26
- $
+ $ sudo cpan DBIx::Class::EncodedColumn
-B<Note:> If you are following along in Ubuntu, you will need to install
-C<Digest::SHA> with the following command to run the example code above:
- sudo apt-get install libdigest-sha-perl
+=head2 Re-Run the DBIC::Schema Model Helper to Include DBIx::Class::EncodedColumn
-B<Note:> You should probably modify this code for production use to
-not read the password from the command line. By having the script
-prompt for the cleartext password, it avoids having the password linger
-in forms such as your C<.bash_history> files (assuming you are using
-BASH as your shell). An example of such a script can be found in
-Appendix 3.
+Next, we can re-run the model helper to have it include
+L<DBIx::Class::EncodedColumn|DBIx::Class::EncodedColumn> in all of the
+Result Classes it generates for us. Simply use the same command we
+saw in Chapters 3 and 4, but add C<,EncodedColumn> to the C<components>
+argument:
+ $ script/myapp_create.pl model DB DBIC::Schema MyApp::Schema \
+ create=static components=TimeStamp,EncodedColumn dbi:SQLite:myapp.db
-=head2 Switch to SHA-1 Password Hashes in the Database
+If you then open one of the Result Classes, you will see that it
+includes EncodedColumn in the C<load_components> line. Take a look at
+C<lib/MyApp/Schema/Result/Users.pm> since that's the main class where we
+want to use hashed and salted passwords:
-Next, we need to change the C<password> column of our C<users> table to
-store this hash value vs. the existing cleartext password. Open
-C<myapp03.sql> in your editor and enter:
+ __PACKAGE__->load_components("InflateColumn::DateTime", "TimeStamp", "EncodedColumn", "Core");
+
+
+=head2 Modify the "password" Column to Use EncodedColumn
+
+Open the file C<lib/MyApp/Schema/Result/Users.pm> and enter the following
+text below the "# DO NOT MODIFY THIS OR ANYTHING ABOVE!" line but above
+the closing "1;":
+
+ # Have the 'password' column use a SHA-1 hash and 10-character salt
+ # with hex encoding; Generate the 'check_password" method
+ __PACKAGE__->add_columns(
+ 'password' => {
+ data_type => "TEXT",
+ size => undef,
+ encode_column => 1,
+ encode_class => 'Digest',
+ encode_args => {salt_length => 10},
+ encode_check_method => 'check_password',
+ },
+ );
+
+This redefines the automatically generated definition for the password
+fields at the top of the Result Class file to now use EncodedColumn
+logic (C<encoded_column> is set to 1). C<encode_class> can be set to
+either C<Digest> to use
+L<DBIx::Class::EncodedColumn::Digest|DBIx::Class::EncodedColumn::Digest>,
+or C<Crypt::Eksblowfish::Bcrypt> for
+L<DBIx::Class::EncodedColumn::Crypt::Eksblowfish::Bcrypt|DBIx::Class::EncodedColumn::Crypt::Eksblowfish::Bcrypt>.
+C<encode_args> is then used to customize the type of Digest you
+selected. Here we only specified the size of the salt to use, but
+we could have also modified the hashing algorithm ('SHA-256' is
+the default) and the format to use ('base64' is the default, but
+'hex' and 'binary' are other options). To use these, you could
+change the C<encode_args> to something like:
+
+ encode_args => {algorithm => 'SHA-1',
+ format => 'hex',
+ salt_length => 10},
+
+
+=head2 Load Hashed Passwords in the Database
+
+Next, let's create a quick script to load some hashed and salted passwords
+into the C<password> column of our C<users> table. Open the file
+C<set_hashed_passwords.pl> in your editor and enter the following text:
+
+ #!/usr/bin/perl
+
+ use strict;
+ use warnings;
+
+ use MyApp::Schema;
+
+ my $schema = MyApp::Schema->connect('dbi:SQLite:myapp.db');
+
+ my @users = $schema->resultset('Users')->all;
+
+ foreach my $user (@users) {
+ $user->password('mypass');
+ $user->update;
+ }
+
+EncodedColumn lets us simple call C<$user->check_password($password)>
+to see if the user has supplied the correct password, or, as we show
+above, call C<$user->update($new_password)> to update the hashed
+password stored for this user.
+
+Then run the following command:
+
+ $ perl -Ilib set_hashed_passwords.pl
+
+We had to use the C<-Ilib> arguement to tell perl to look under the
+C<lib> directory for our C<MyApp::Schema> model.
+
+Then dump the users table to verify that it worked:
+
+ $ sqlite3 myapp.db "select * from users"
+ 1|test01|38d3974fa9e9263099f7bc2574284b2f55473a9bM=fwpX2NR8|t01@na.com|Joe|Blow|1
+ 2|test02|6ed8586587e53e0d7509b1cfed5df08feadc68cbMJlnPyPt0I|t02@na.com|Jane|Doe|1
+ 3|test03|af929a151340c6aed4d54d7e2651795d1ad2e2f7UW8dHoGv9z|t03@na.com|No|Go|0
+
+As you can see, the passwords are much harder to steal from the
+database. Also note that this demonstrates how to use a DBIx::Class
+model outside of your web application -- a very useful feature in many
+situations.
+
+
+=head2 Enable Hashed and Salted Passwords
+
+Edit C<lib/MyApp.pm> and update it to match the following text (the only change
+is to the C<password_type> field):
+
+ # Configure SimpleDB Authentication
+ __PACKAGE__->config->{'Plugin::Authentication'} = {
+ default => {
+ class => 'SimpleDB',
+ user_model => 'DB::Users',
+ password_type => 'self_check',
+ },
+ };
+
+The use of C<self_check> will cause
+Catalyst::Plugin::Authentication::Store::DBIC to call the
+C<check_password> method we enabled on our C<password> columns.
- --
- -- Convert passwords to SHA-1 hashes
- --
- UPDATE users SET password = 'e727d1464ae12436e899a726da5b2f11d8381b26' WHERE id = 1;
- UPDATE users SET password = 'e727d1464ae12436e899a726da5b2f11d8381b26' WHERE id = 2;
- UPDATE users SET password = 'e727d1464ae12436e899a726da5b2f11d8381b26' WHERE id = 3;
-
-Then use the following command to update the SQLite database:
-
- $ sqlite3 myapp.db < myapp03.sql
-
-B<Note:> We are using SHA-1 hashes here, but many other hashing
-algorithms are supported. See C<Digest> for more information.
-
-
-=head2 Enable SHA-1 Hash Passwords in
-C<Catalyst::Plugin::Authentication::Store::DBIC>
-
-Edit C<myapp.conf> and update it to match (the C<password_type> and
-C<password_hash_type> are new, everything else is the same):
-
- name MyApp
- <authentication>
- default_realm dbic
- <realms>
- <dbic>
- <credential>
- # Note this first definition would be the same as setting
- # __PACKAGE__->config->{authentication}->{realms}->{dbic}
- # ->{credential} = 'Password' in lib/MyApp.pm
- #
- # Specify that we are going to do password-based auth
- class Password
- # This is the name of the field in the users table with the
- # password stored in it
- password_field password
- # Switch to more secure hashed passwords
- password_type hashed
- # Use the SHA-1 hashing algorithm
- password_hash_type SHA-1
- </credential>
- <store>
- # Use DBIC to retrieve username, password & role information
- class DBIx::Class
- # This is the model object created by Catalyst::Model::DBIC
- # from your schema (you created 'MyApp::Schema::User' but as
- # the Catalyst startup debug messages show, it was loaded as
- # 'MyApp::Model::DB::Users').
- # NOTE: Omit 'MyApp::Model' here just as you would when using
- # '$c->model("DB::Users)'
- user_class DB::Users
- # This is the name of the field in your 'users' table that
- # contains the user's name
- id_field username
- </store>
- </dbic>
- </realms>
- </authentication>
=head2 Try Out the Hashed Passwords
$ script/myapp_server.pl
You should now be able to go to L<http://localhost:3000/books/list> and
-login as before. When done, click the "Logout" link on the login page
+login as before. When done, click the "logout" link on the login page
(or point your browser at L<http://localhost:3000/logout>).
=head1 USING THE SESSION FOR FLASH
-As discussed in Part 3 of the tutorial, C<flash> allows you to set
-variables in a way that is very similar to C<stash>, but it will
-remain set across multiple requests. Once the value is read, it
-is cleared (unless reset). Although C<flash> has nothing to do with
-authentication, it does leverage the same session plugins. Now that
-those plugins are enabled, let's go back and improve the "delete
-and redirect with query parameters" code seen at the end of the
-L<Basic CRUD|Catalyst::Manual::Tutorial::BasicCRUD> part of the
-tutorial.
+As discussed in the previous chapter of the tutorial, C<flash> allows
+you to set variables in a way that is very similar to C<stash>, but it
+will remain set across multiple requests. Once the value is read, it
+is cleared (unless reset). Although C<flash> has nothing to do with
+authentication, it does leverage the same session plugins. Now that
+those plugins are enabled, let's go back and update the "delete and
+redirect with query parameters" code seen at the end of the L<Basic
+CRUD|Catalyst::Manual::Tutorial::BasicCRUD> chapter of the tutorial to
+take advantage of C<flash>.
First, open C<lib/MyApp/Controller/Books.pm> and modify C<sub delete>
to match the following (everything after the model search line of code
has changed):
- =head2 delete
+ =head2 delete
Delete a book
-
+
=cut
- sub delete : Local {
- # $id = primary key of book to delete
- my ($self, $c, $id) = @_;
+ sub delete :Chained('object') :PathPart('delete') :Args(0) {
+ my ($self, $c) = @_;
- # Search for the book and then delete it
- $c->model('DB::Books')->search({id => $id})->delete_all;
+ # Use the book object saved by 'object' and delete it along
+ # with related 'book_authors' entries
+ $c->stash->{object}->delete;
# Use 'flash' to save information across requests until it's read
$c->flash->{status_msg} = "Book deleted";
-
+
# Redirect the user back to the list page
- $c->response->redirect($c->uri_for('/books/list'));
+ $c->response->redirect($c->uri_for($self->action_for('list')));
}
-Next, open C<root/lib/site/layout> and update the TT code to pull from
+Next, open C<root/src/wrapper.tt2> and update the TT code to pull from
flash vs. the C<status_msg> query parameter:
- <div id="header">[% PROCESS site/header %]</div>
-
+ ...
<div id="content">
- <span class="message">[% status_msg || Catalyst.flash.status_msg %]</span>
- <span class="error">[% error_msg %]</span>
- [% content %]
- </div>
-
- <div id="footer">[% PROCESS site/footer %]</div>
+ [%# Status and error messages %]
+ <span class="message">[% status_msg || c.flash.status_msg %]</span>
+ <span class="error">[% error_msg %]</span>
+ [%# This is where TT will stick all of your template's contents. -%]
+ [% content %]
+ </div><!-- end content -->
+ ...
+
+Although the sample above only shows the C<content> div, leave the
+rest of the file intact -- the only change we made to the C<wrapper.tt2>
+was to add "C<|| c.request.params.status_msg>" to the
+C<E<lt>span class="message"E<gt>> line.
=head2 Try Out Flash
-Restart the development server and point your browser to
-L<http://localhost:3000/books/url_create/Test/1/4> to create an extra
-several books. Click the "Return to list" link and delete one of the
-"Test" books you just added. The C<flash> mechanism should retain our
+Restart the development server, log in, and then point your browser to
+L<http://localhost:3000/books/url_create/Test/1/4> to create an extra
+several books. Click the "Return to list" link and delete one of the
+"Test" books you just added. The C<flash> mechanism should retain our
"Book deleted" status message across the redirect.
B<NOTE:> While C<flash> will save information across multiple requests,
L<Catalyst::Plugin::Session|Catalyst::Plugin::Session> for additional
information.
+
=head2 Switch To Flash-To-Stash
-Although the a use of flash above is certainly an improvement over the
-C<status_msg> we employed in Part 4 of the tutorial, the C<status_msg
-|| Catalyst.flash.status_msg> statement is a little ugly. A nice
-alternative is to use the C<flash_to_stash> feature that automatically
-copies the content of flash to stash. This makes your code controller
-and template code work regardless of where it was directly access, a
-forward, or a redirect. To enable C<flash_to_stash>, you can either
-set the value in C<lib/MyApp.pm> by changing the default
+Although the a use of flash above works well, the
+C<status_msg || c.flash.status_msg> statement is a little ugly. A nice
+alternative is to use the C<flash_to_stash> feature that automatically
+copies the content of flash to stash. This makes your controller
+and template code work regardless of where it was directly access, a
+forward, or a redirect. To enable C<flash_to_stash>, you can either
+set the value in C<lib/MyApp.pm> by changing the default
C<__PACKAGE__-E<gt>config> setting to something like:
__PACKAGE__->config(
- name => 'MyApp',
+ name => 'MyApp',
session => {flash_to_stash => 1}
);
flash_to_stash 1
</session>
-The C<__PACKAGE__-E<gt>config> option is probably preferable here
-since it's not something you will want to change at runtime without it
+The C<__PACKAGE__-E<gt>config> option is probably preferable here
+since it's not something you will want to change at runtime without it
possibly breaking some of your code.
-Then edit C<root/lib/site/layout> and change the C<status_msg> line
-to look like the following:
+Then edit C<root/src/wrapper.tt2> and change the C<status_msg> line
+to match the following:
<span class="message">[% status_msg %]</span>
Restart the development server and go to
-L<http://localhost:3000/books/list> in your browser. Delete another
+L<http://localhost:3000/books/list> in your browser. Delete another
of the "Test" books you added in the previous step. Flash should still
maintain the status message across the redirect even though you are no
-longer explicitly accessing C<Catalyst.flash>.
+longer explicitly accessing C<c.flash>.
=head1 AUTHOR
Please report any errors, issues or suggestions to the author. The
most recent version of the Catalyst Tutorial can be found at
-L<http://dev.catalyst.perl.org/repos/Catalyst/trunk/Catalyst-Manual/lib/Catalyst/Manual/Tutorial/>.
+L<http://dev.catalyst.perl.org/repos/Catalyst/Catalyst-Manual/5.70/trunk/lib/Catalyst/Manual/Tutorial/>.
Copyright 2006-2008, Kennedy Clark, under Creative Commons License
-(L<http://creativecommons.org/licenses/by-nc-sa/2.5/>).
+(L<http://creativecommons.org/licenses/by-sa/3.0/us/>).
projects / catagits/Catalyst-Manual.git / blobdiff