3 Catalyst::Manual::Tutorial::Authentication - Catalyst Tutorial - Part 4: Authentication
8 This is B<Part 4 of 9> for the Catalyst tutorial.
10 L<Tutorial Overview|Catalyst::Manual::Tutorial>
16 L<Introduction|Catalyst::Manual::Tutorial::Intro>
20 L<Catalyst Basics|Catalyst::Manual::Tutorial::CatalystBasics>
24 L<Basic CRUD|Catalyst::Manual::Tutorial::BasicCRUD>
32 L<Authorization|Catalyst::Manual::Tutorial::Authorization>
36 L<Debugging|Catalyst::Manual::Tutorial::Debugging>
40 L<Testing|Catalyst::Manual::Tutorial::Testing>
44 L<AdvancedCRUD|Catalyst::Manual::Tutorial::AdvancedCRUD>
48 L<Appendices|Catalyst::Manual::Tutorial::Appendices>
55 Now that we finally have a simple yet functional application, we can
56 focus on providing authentication (with authorization coming next in
59 This part of the tutorial is divided into two main sections: 1) basic,
60 cleartext authentication and 2) hash-based authentication.
62 You can checkout the source code for this example from the catalyst
63 subversion repository as per the instructions in
64 L<Catalyst::Manual::Tutorial::Intro>
66 =head1 BASIC AUTHENTICATION
68 This section explores how to add authentication logic to a Catalyst
72 =head2 Add Users and Roles to the Database
74 First, we add both user and role information to the database (we will
75 add the role information here although it will not be used until the
76 authorization section, Part 5). Create a new SQL script file by opening
77 C<myapp02.sql> in your editor and insert:
80 -- Add users and roles tables, along with a many-to-many join table
83 id INTEGER PRIMARY KEY,
92 id INTEGER PRIMARY KEY,
95 CREATE TABLE user_roles (
98 PRIMARY KEY (user_id, role_id)
101 -- Load up some initial test data
103 INSERT INTO users VALUES (1, 'test01', 'mypass', 't01@na.com', 'Joe', 'Blow', 1);
104 INSERT INTO users VALUES (2, 'test02', 'mypass', 't02@na.com', 'Jane', 'Doe', 1);
105 INSERT INTO users VALUES (3, 'test03', 'mypass', 't03@na.com', 'No', 'Go', 0);
106 INSERT INTO roles VALUES (1, 'user');
107 INSERT INTO roles VALUES (2, 'admin');
108 INSERT INTO user_roles VALUES (1, 1);
109 INSERT INTO user_roles VALUES (1, 2);
110 INSERT INTO user_roles VALUES (2, 1);
111 INSERT INTO user_roles VALUES (3, 1);
113 Then load this into the C<myapp.db> database with the following command:
115 $ sqlite3 myapp.db < myapp02.sql
118 =head2 Add User and Role Information to DBIC Schema
120 This step adds DBIC-based classes for the user-related database tables
121 (the role information will not be used until Part 5):
123 Edit C<lib/MyAppDB.pm> and update the contents to match (only the
124 C<MyAppDB =E<gt> [qw/Book BookAuthor Author User UserRole Role/]> line
131 MyAppDB -- DBIC Schema Class
135 # Our schema needs to inherit from 'DBIx::Class::Schema'
136 use base qw/DBIx::Class::Schema/;
138 # Need to load the DB Model classes here.
139 # You can use this syntax if you want:
140 # __PACKAGE__->load_classes(qw/Book BookAuthor Author User UserRole Role/);
141 # Also, if you simply want to load all of the classes in a directory
142 # of the same name as your schema class (as we do here) you can use:
143 # __PACKAGE__->load_classes(qw//);
144 # But the variation below is more flexible in that it can be used to
145 # load from multiple namespaces.
146 __PACKAGE__->load_classes({
147 MyAppDB => [qw/Book BookAuthor Author User UserRole Role/]
153 =head2 Create New "Result Source Objects"
155 Create the following three files with the content shown below.
157 C<lib/MyAppDB/User.pm>:
159 package MyAppDB::User;
161 use base qw/DBIx::Class/;
163 # Load required DBIC stuff
164 __PACKAGE__->load_components(qw/PK::Auto Core/);
166 __PACKAGE__->table('users');
167 # Set columns in table
168 __PACKAGE__->add_columns(qw/id username password email_address first_name last_name/);
169 # Set the primary key for the table
170 __PACKAGE__->set_primary_key('id');
178 # 1) Name of relationship, DBIC will create accessor with this name
179 # 2) Name of the model class referenced by this relationship
180 # 3) Column name in *foreign* table
181 __PACKAGE__->has_many(map_user_role => 'MyAppDB::UserRole', 'user_id');
186 MyAppDB::User - A model object representing a person with access to the system.
190 This is an object that represents a row in the 'users' table of your application
191 database. It uses DBIx::Class (aka, DBIC) to do ORM.
193 For Catalyst, this is designed to be used through MyApp::Model::MyAppDB.
194 Offline utilities may wish to use this class directly.
201 C<lib/MyAppDB/Role.pm>:
203 package MyAppDB::Role;
205 use base qw/DBIx::Class/;
207 # Load required DBIC stuff
208 __PACKAGE__->load_components(qw/PK::Auto Core/);
210 __PACKAGE__->table('roles');
211 # Set columns in table
212 __PACKAGE__->add_columns(qw/id role/);
213 # Set the primary key for the table
214 __PACKAGE__->set_primary_key('id');
222 # 1) Name of relationship, DBIC will create accessor with this name
223 # 2) Name of the model class referenced by this relationship
224 # 3) Column name in *foreign* table
225 __PACKAGE__->has_many(map_user_role => 'MyAppDB::UserRole', 'role_id');
230 MyAppDB::Role - A model object representing a class of access permissions to
235 This is an object that represents a row in the 'roles' table of your
236 application database. It uses DBIx::Class (aka, DBIC) to do ORM.
238 For Catalyst, this is designed to be used through MyApp::Model::MyAppDB.
239 "Offline" utilities may wish to use this class directly.
246 C<lib/MyAppDB/UserRole.pm>:
248 package MyAppDB::UserRole;
250 use base qw/DBIx::Class/;
252 # Load required DBIC stuff
253 __PACKAGE__->load_components(qw/PK::Auto Core/);
255 __PACKAGE__->table('user_roles');
256 # Set columns in table
257 __PACKAGE__->add_columns(qw/user_id role_id/);
258 # Set the primary key for the table
259 __PACKAGE__->set_primary_key(qw/user_id role_id/);
267 # 1) Name of relationship, DBIC will create accessor with this name
268 # 2) Name of the model class referenced by this relationship
269 # 3) Column name in *this* table
270 __PACKAGE__->belongs_to(user => 'MyAppDB::User', 'user_id');
274 # 1) Name of relationship, DBIC will create accessor with this name
275 # 2) Name of the model class referenced by this relationship
276 # 3) Column name in *this* table
277 __PACKAGE__->belongs_to(role => 'MyAppDB::Role', 'role_id');
282 MyAppDB::UserRole - A model object representing the JOIN between Users and Roles.
286 This is an object that represents a row in the 'user_roles' table of your application
287 database. It uses DBIx::Class (aka, DBIC) to do ORM.
289 You probably won't need to use this class directly -- it will be automatically
290 used by DBIC where joins are needed.
292 For Catalyst, this is designed to be used through MyApp::Model::MyAppDB.
293 Offline utilities may wish to use this class directly.
299 The code for these three result source classes is obviously very familiar to the C<Book>, C<Author>, and C<BookAuthor> classes created in Part 2.
302 =head2 Sanity-Check Reload of Development Server
304 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:
306 $ script/myapp_server.pl
308 Look for the three new model objects in the startup debug output:
311 .-------------------------------------------------------------------+----------.
313 +-------------------------------------------------------------------+----------+
314 | MyApp::Controller::Books | instance |
315 | MyApp::Controller::Root | instance |
316 | MyApp::Model::MyAppDB | instance |
317 | MyApp::Model::MyAppDB::Author | class |
318 | MyApp::Model::MyAppDB::Book | class |
319 | MyApp::Model::MyAppDB::BookAuthor | class |
320 | MyApp::Model::MyAppDB::Role | class |
321 | MyApp::Model::MyAppDB::User | class |
322 | MyApp::Model::MyAppDB::UserRole | class |
323 | MyApp::View::TT | instance |
324 '-------------------------------------------------------------------+----------'
327 Again, notice that your "result source" classes have been "re-loaded" by Catalyst under C<MyApp::Model>.
330 =head2 Include Authentication and Session Plugins
332 Edit C<lib/MyApp.pm> and update it as follows (everything below C<StackTrace> is new):
344 Session::Store::FastMmap
345 Session::State::Cookie
348 The C<Authentication> plugin supports
349 Authentication while the C<Session> plugins are required to maintain
350 state across multiple HTTP requests.
352 Note that the only required Authentication class is the main
353 one. This is a change that occured in version 0.09999_01
354 of the C<Authentication> plugin. You B<do not need> to specify a
355 particular Authentication::Store or Authentication::Credential plugin.
356 Instead, indicate the Store and Credential you want to use in your application
357 configuration (see below).
359 Note that there are several
360 options for L<Session::Store|Catalyst::Plugin::Session::Store>
361 (L<Session::Store::FastMmap|Catalyst::Plugin::Session::Store::FastMmap>
362 is generally a good choice if you are on Unix; try
363 L<Session::Store::File|Catalyst::Plugin::Session::Store::File> if you
364 are on Win32) -- consult
365 L<Session::Store|Catalyst::Plugin::Session::Store> and its subclasses
366 for additional information and options (for example to use a
367 database-backed session store).
370 =head2 Configure Authentication
372 Although C<__PACKAGE__-E<gt>config(name =E<gt> 'value');> is still
373 supported, newer Catalyst applications tend to place all configuration
374 information in C<myapp.yml> and automatically load this information into
375 C<MyApp-E<gt>config> using the
376 L<ConfigLoader|Catalyst::Plugin::ConfigLoader> plugin. Here, we need
377 to load several parameters that tell
378 L<Catalyst::Plugin::Authentication|Catalyst::Plugin::Authentication>
379 where to locate information in your database. To do this, edit the
380 C<myapp.yml> YAML and update it to match:
390 password_field: password
391 password_type: self_check
394 # This is the model object created by Catalyst::Model::DBIC from your
395 # schema (you created 'MyAppDB::User' but as the Catalyst startup
396 # debug messages show, it was loaded as 'MyApp::Model::MyAppDB::User').
397 # NOTE: Omit 'MyApp::Model' to avoid a component lookup issue in Catalyst 5.66
398 user_class: MyApp::Users
399 # This is the name of the field in your 'users' table that contains the user's name
403 ignore_fields_in_find: [ 'remote_name' ]
405 Inline comments in the code above explain how each field is being used.
407 B<TIP>: Although YAML uses a very simple and easy-to-ready format, it
408 does require the use of a consistent level of indenting. Be sure you
409 line up everything on a given 'level' with the same number of indents.
410 Also, be sure not to use C<tab> characters (YAML does not support them
411 because they are handled inconsistently across editors).
414 =head2 Add Login and Logout Controllers
416 Use the Catalyst create script to create two stub controller files:
418 $ script/myapp_create.pl controller Login
419 $ script/myapp_create.pl controller Logout
421 B<NOTE>: You could easily use a single controller here. For example,
422 you could have a C<User> controller with both C<login> and C<logout>
423 actions. Remember, Catalyst is designed to be very flexible, and leaves
424 such matters up to you, the designer and programmer.
426 Then open C<lib/MyApp/Controller/Login.pm>, locate the C<sub index :
427 Private> method (this was automatically inserted by the helpers when we
428 created the Login controller above), and delete this line:
430 $c->response->body('Matched MyApp::Controller::Login in Login.');
432 Then update it to match:
440 sub index : Private {
443 # Get the username and password from form
444 my $username = $c->request->params->{username} || "";
445 my $password = $c->request->params->{password} || "";
447 # If the username and password values were found in form
448 if ($username && $password) {
449 # Attempt to log the user in
450 if ($c->authenticate({ username => $username,
451 password => $password} )) {
452 # If successful, then let them use the application
453 $c->response->redirect($c->uri_for('/books/list'));
456 # Set an error message
457 $c->stash->{error_msg} = "Bad username or password.";
461 # If either of above don't work out, send to the login page
462 $c->stash->{template} = 'login.tt2';
465 This controller fetches the C<username> and C<password> values from the
466 login form and attempts to authenticate the user. If successful, it
467 redirects the user to the book list page. If the login fails, the user
468 will stay at the login page but receive an error message. If the
469 C<username> and C<password> values are not present in the form, the
470 user will be taken to the empty login form.
472 Note that we could have used something like C<sub default :Private>;
473 however, the use of C<default> actions is discouraged because it does
474 not receive path args as with other actions. The recommended practice
475 is to only use C<default> in C<MyApp::Controller::Root>.
477 Another option would be to use something like
478 C<sub base :Path :Args(0) {...}> (where the C<...> refers to the login
479 code shown in C<sub index : Private> above). We are using C<sub base
480 :Path :Args(0) {...}> here to specifically match the URL C</login>.
481 C<Path> actions (aka, "literal actions") create URI matches relative to
482 the namespace of the controller where they are defined. Although
483 C<Path> supports arguments that allow relative and absolute paths to be
484 defined, here we use an empty C<Path> definition to match on just the
485 name of the controller itself. The method name, C<base>, is arbitrary.
486 We make the match even more specific with the C<:Args(0)> action
487 modifier -- this forces the match on I<only> C</login>, not
488 C</login/somethingelse>.
490 Next, update the corresponding method in C<lib/MyApp/Controller/Logout.pm>
499 sub index : Private {
502 # Clear the user's state
505 # Send the user to the starting point
506 $c->response->redirect($c->uri_for('/'));
509 As with the login controller, be sure to delete the
510 C<$c->response->body('Matched MyApp::Controller::Logout in Logout.');>
511 line of the C<sub index>.
514 =head2 Add a Login Form TT Template Page
516 Create a login form by opening C<root/src/login.tt2> and inserting:
518 [% META title = 'Login' %]
521 <form method="post" action=" [% Catalyst.uri_for('/login') %] ">
525 <td><input type="text" name="username" size="40" /></td>
529 <td><input type="password" name="password" size="40" /></td>
532 <td colspan="2"><input type="submit" name="submit" value="Submit" /></td>
538 =head2 Add Valid User Check
540 We need something that provides enforcement for the authentication
541 mechanism -- a I<global> mechanism that prevents users who have not
542 passed authentication from reaching any pages except the login page.
543 This is generally done via an C<auto> action/method (prior to Catalyst
544 v5.66, this sort of thing would go in C<MyApp.pm>, but starting in
545 v5.66, the preferred location is C<lib/MyApp/Controller/Root.pm>).
547 Edit the existing C<lib/MyApp/Controller/Root.pm> class file and insert
548 the following method:
552 Check if there is a user and, if not, forward to login page
556 # Note that 'auto' runs after 'begin' but before your actions and that
557 # 'auto' "chain" (all from application path to most specific class are run)
558 # See the 'Actions' section of 'Catalyst::Manual::Intro' for more info.
562 # Allow unauthenticated users to reach the login page. This
563 # allows anauthenticated users to reach any action in the Login
564 # controller. To lock it down to a single action, we could use:
565 # if ($c->action eq $c->controller('Login')->action_for('index'))
566 # to only allow unauthenticated access to the C<index> action we
568 if ($c->controller eq $c->controller('Login')) {
572 # If a user doesn't exist, force login
573 if (!$c->user_exists) {
574 # Dump a log message to the development server debug output
575 $c->log->debug('***Root::auto User not found, forwarding to /login');
576 # Redirect the user to the login page
577 $c->response->redirect($c->uri_for('/login'));
578 # Return 0 to cancel 'post-auto' processing and prevent use of application
582 # User found, so return 1 to continue with processing after this 'auto'
586 B<Note:> Catalyst provides a number of different types of actions, such
587 as C<Local>, C<Regex>, and C<Private>. You should refer to
588 L<Catalyst::Manual::Intro> for a more detailed explanation, but the
589 following bullet points provide a quick introduction:
595 The majority of application use C<Local> actions for items that respond
596 to user requests and C<Private> actions for those that do not directly
597 respond to user input.
601 There are five types of C<Private> actions: C<begin>, C<end>,
602 C<default>, C<index>, and C<auto>.
606 With C<begin>, C<end>, C<default>, C<index> private actions, only the
607 most specific action of each type will be called. For example, if you
608 define a C<begin> action in your controller it will I<override> a
609 C<begin> action in your application/root controller -- I<only> the
610 action in your controller will be called.
614 Unlike the other actions where only a single method is called for each
615 request, I<every> auto action along the chain of namespaces will be
616 called. Each C<auto> action will be called I<from the application/root
617 controller down through the most specific class>.
621 By placing the authentication enforcement code inside the C<auto> method
622 of C<lib/MyApp/Controller/Root.pm> (or C<lib/MyApp.pm>), it will be
623 called for I<every> request that is received by the entire application.
626 =head2 Displaying Content Only to Authenticated Users
628 Let's say you want to provide some information on the login page that
629 changes depending on whether the user has authenticated yet. To do
630 this, open C<root/src/login.tt2> in your editor and add the following
631 lines to the bottom of the file:
635 # This code illustrates how certain parts of the TT
636 # template will only be shown to users who have logged in
638 [% IF Catalyst.user_exists %]
639 Please Note: You are already logged in as '[% Catalyst.user.username %]'.
640 You can <a href="[% Catalyst.uri_for('/logout') %]">logout</a> here.
642 You need to log in to use this application.
645 Note that this whole block is a comment because the "#" appears
646 immediate after the "[%" (with no spaces in between). Although it
647 can be a handy way to temporarily "comment out" a whole block of
648 TT code, it's probably a little too subtle for use in "normal"
653 Although most of the code is comments, the middle few lines provide a
654 "you are already logged in" reminder if the user returns to the login
655 page after they have already authenticated. For users who have not yet
656 authenticated, a "You need to log in..." message is displayed (note the
657 use of an IF-THEN-ELSE construct in TT).
660 =head2 Try Out Authentication
662 Press C<Ctrl-C> to kill the previous server instance (if it's still
663 running) and restart it:
665 $ script/myapp_server.pl
667 B<IMPORTANT NOTE>: If you happen to be using Internet Explorer, you may
668 need to use the command C<script/myapp_server.pl -k> to enable the
669 keepalive feature in the development server. Otherwise, the HTTP
670 redirect on successful login may not work correctly with IE (it seems to
671 work without -k if you are running the web browser and development
672 server on the same machine). If you are using browser a browser other
673 than IE, it should work either way. If you want to make keepalive the
674 default, you can edit C<script/myapp_server.pl> and change the
675 initialization value for C<$keepalive> to C<1>. (You will need to do
676 this every time you create a new Catalyst application or rebuild the
677 C<myapp_server.pl> script.)
679 Now trying going to L<http://localhost:3000/books/list> and you should
680 be redirected to the login page, hitting Shift+Reload if necessary (the
681 "You are already logged in" message should I<not> appear -- if it does,
682 click the C<logout> button and try again). Note the C<***Root::auto User
683 not found...> debug message in the development server output. Enter
684 username C<test01> and password C<mypass>, and you should be taken to
687 Open C<root/src/books/list.tt2> and add the following lines to the
691 <a href="[% Catalyst.uri_for('/login') %]">Login</a>
692 <a href="[% Catalyst.uri_for('form_create') %]">Create</a>
695 Reload your browser and you should now see a "Login" and "Create" links
696 at the bottom of the page (as mentioned earlier, you can update template
697 files without reloading the development server). Click the first link
698 to return to the login page. This time you I<should> see the "You are
699 already logged in" message.
701 Finally, click the C<You can logout here> link on the C</login> page.
702 You should stay at the login page, but the message should change to "You
703 need to log in to use this application."
706 =head1 USING PASSWORD HASHES
708 In this section we increase the security of our system by converting
709 from cleartext passwords to SHA-1 password hashes.
711 B<Note:> This section is optional. You can skip it and the rest of the
712 tutorial will function normally.
714 Note that even with the techniques shown in this section, the browser
715 still transmits the passwords in cleartext to your application. We are
716 just avoiding the I<storage> of cleartext passwords in the database by
717 using a SHA-1 hash. If you are concerned about cleartext passwords
718 between the browser and your application, consider using SSL/TLS, made
719 easy with the Catalyst plugin Catalyst::Plugin:RequireSSL.
722 =head2 Get a SHA-1 Hash for the Password
724 Catalyst uses the C<Digest> module to support a variety of hashing
725 algorithms. Here we will use SHA-1 (SHA = Secure Hash Algorithm).
726 First, we should compute the SHA-1 hash for the "mypass" password we are
727 using. The following command-line Perl script provides a "quick and
728 dirty" way to do this:
730 $ perl -MDigest::SHA -e 'print Digest::SHA::sha1_hex("mypass"), "\n"'
731 e727d1464ae12436e899a726da5b2f11d8381b26
734 B<Note:> You should probably modify this code for production use to
735 not read the password from the command line. By having the script
736 prompt for the cleartext password, it avoids having the password linger
737 in forms such as your C<.bash_history> files (assuming you are using
738 BASH as your shell). An example of such a script can be found in
742 =head2 Switch to SHA-1 Password Hashes in the Database
744 Next, we need to change the C<password> column of our C<users> table to
745 store this hash value vs. the existing cleartext password. Open
746 C<myapp03.sql> in your editor and enter:
749 -- Convert passwords to SHA-1 hashes
751 UPDATE users SET password = 'e727d1464ae12436e899a726da5b2f11d8381b26' WHERE id = 1;
752 UPDATE users SET password = 'e727d1464ae12436e899a726da5b2f11d8381b26' WHERE id = 2;
753 UPDATE users SET password = 'e727d1464ae12436e899a726da5b2f11d8381b26' WHERE id = 3;
755 Then use the following command to update the SQLite database:
757 $ sqlite3 myapp.db < myapp03.sql
759 B<Note:> We are using SHA-1 hashes here, but many other hashing
760 algorithms are supported. See C<Digest> for more information.
763 =head2 Enable SHA-1 Hash Passwords in
764 C<Catalyst::Plugin::Authentication::Store::DBIC>
766 Edit C<myapp.yml> and update it to match (the C<password_type> and
767 C<password_hash_type> are new, everything else is the same):
773 # Note this first definition would be the same as setting
774 # __PACKAGE__->config->{authentication}->{dbic}->{user_class} = 'MyAppDB::User'
775 # in lib/MyApp.pm (IOW, each hash key becomes a "name:" in the YAML file).
777 # This is the model object created by Catalyst::Model::DBIC from your
778 # schema (you created 'MyAppDB::User' but as the Catalyst startup
779 # debug messages show, it was loaded as 'MyApp::Model::MyAppDB::User').
780 # NOTE: Omit 'MyApp::Model' here just as you would when using
781 # '$c->model("MyAppDB::User)'
782 user_class: MyAppDB::User
783 # This is the name of the field in your 'users' table that contains the user's name
785 # This is the name of the field in your 'users' table that contains the password
786 password_field: password
787 # Other options can go here for hashed passwords
788 # Enabled hashed passwords
789 password_type: hashed
790 # Use the SHA-1 hashing algorithm
791 password_hash_type: SHA-1
794 =head2 Try Out the Hashed Passwords
796 Press C<Ctrl-C> to kill the previous server instance (if it's still
797 running) and restart it:
799 $ script/myapp_server.pl
801 You should now be able to go to L<http://localhost:3000/books/list> and
802 login as before. When done, click the "Logout" link on the login page
803 (or point your browser at L<http://localhost:3000/logout>).
805 B<Note:> If you receive the debug screen in your browser with a
806 C<Can't call method "stash" on an undefined value...> error message,
807 make sure that you are using v0.07 of
808 L<Catalyst::Plugin::Authorization::ACL|Catalyst::Plugin::Authorization::ACL>.
809 The following command can be a useful way to quickly dump the version number
810 of this module on your system:
812 perl -MCatalyst::Plugin::Authorization::ACL -e 'print $Catalyst::Plugin::Authorization::ACL::VERSION, "\n";'
815 =head1 USING THE SESSION FOR FLASH
817 As discussed in Part 3 of the tutorial, C<flash> allows you to set
818 variables in a way that is very similar to C<stash>, but it will
819 remain set across multiple requests. Once the value is read, it
820 is cleared (unless reset). Although C<flash> has nothing to do with
821 authentication, it does leverage the same session plugins. Now that
822 those plugins are enabled, let's go back and improve the "delete
823 and redirect with query parameters" code seen at the end of the
824 L<Basic CRUD|Catalyst::Manual::Tutorial::BasicCRUD> part of the
827 First, open C<lib/MyApp/Controller/Books.pm> and modify C<sub delete>
828 to match the following:
837 # $id = primary key of book to delete
838 my ($self, $c, $id) = @_;
840 # Search for the book and then delete it
841 $c->model('MyAppDB::Book')->search({id => $id})->delete_all;
843 # Use 'flash' to save information across requests until it's read
844 $c->flash->{status_msg} = "Book deleted";
846 # Redirect the user back to the list page with status msg as an arg
847 $c->response->redirect($c->uri_for('/books/list'));
850 Next, open C<root/lib/site/layout> and update the TT code to pull from
851 flash vs. the C<status_msg> query parameter:
853 <div id="header">[% PROCESS site/header %]</div>
856 <span class="message">[% status_msg || Catalyst.flash.status_msg %]</span>
857 <span class="error">[% error_msg %]</span>
861 <div id="footer">[% PROCESS site/footer %]</div>
866 Restart the development server and point your browser to
867 L<http://localhost:3000/books/url_create/Test/1/4> to create an extra
868 book. Click the "Return to list" link and delete the "Test" book you
869 just added. The C<flash> mechanism should retain our "Book deleted"
870 status message across the redirect.
872 B<NOTE:> While C<flash> will save information across multiple requests,
873 I<it does get cleared the first time it is read>. In general, this is
874 exactly what you want -- the C<flash> message will get displayed on
875 the next screen where it's appropriate, but it won't "keep showing up"
876 after that first time (unless you reset it). Please refer to
877 L<Catalyst::Plugin::Session|Catalyst::Plugin::Session> for additional
883 Kennedy Clark, C<hkclark@gmail.com>
885 Please report any errors, issues or suggestions to the author. The
886 most recent version of the Catalyst Tutorial can be found at
887 L<http://dev.catalyst.perl.org/repos/Catalyst/trunk/Catalyst-Manual/lib/Catalyst/Manual/Tutorial/>.
889 Copyright 2006, Kennedy Clark, under Creative Commons License
890 (L<http://creativecommons.org/licenses/by-nc-sa/2.5/>).