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):
342 Authentication::Store::DBIC
343 Authentication::Credential::Password
346 Session::Store::FastMmap
347 Session::State::Cookie
350 The three C<Authentication> plugins work together to support
351 Authentication while the C<Session> plugins are required to maintain
352 state across multiple HTTP requests. Note that there are several
353 options for L<Session::Store|Catalyst::Plugin::Session::Store>
354 (L<Session::Store::FastMmap|Catalyst::Plugin::Session::Store::FastMmap>
355 is generally a good choice if you are on Unix; try
356 L<Session::Store::File|Catalyst::Plugin::Session::Store::File> if you
357 are on Win32) -- consult
358 L<Session::Store|Catalyst::Plugin::Session::Store> and its subclasses
359 for additional information and options (for example to use a
360 database-backed session store).
363 =head2 Configure Authentication
365 Although C<__PACKAGE__-E<gt>config(name =E<gt> 'value');> is still
366 supported, newer Catalyst applications tend to place all configuration
367 information in C<myapp.yml> and automatically load this information into
368 C<MyApp-E<gt>config> using the
369 L<ConfigLoader|Catalyst::Plugin::ConfigLoader> plugin. Here, we need
370 to load several parameters that tell
371 L<Catalyst::Plugin::Authentication|Catalyst::Plugin::Authentication>
372 where to locate information in your database. To do this, edit the
373 C<myapp.yml> YAML and update it to match:
379 # Note this first definition would be the same as setting
380 # __PACKAGE__->config->{authentication}->{dbic}->{user_class} = 'MyAppDB::User'
381 # in lib/MyApp.pm (IOW, each hash key becomes a "name:" in the YAML file).
383 # This is the model object created by Catalyst::Model::DBIC from your
384 # schema (you created 'MyAppDB::User' but as the Catalyst startup
385 # debug messages show, it was loaded as 'MyApp::Model::MyAppDB::User').
386 # NOTE: Omit 'MyApp::Model' to avoid a component lookup issue in Catalyst 5.66
387 user_class: MyAppDB::User
388 # This is the name of the field in your 'users' table that contains the user's name
390 # This is the name of the field in your 'users' table that contains the password
391 password_field: password
392 # Other options can go here for hashed passwords
394 Inline comments in the code above explain how each field is being used.
396 B<TIP>: Although YAML uses a very simple and easy-to-ready format, it
397 does require the use of a consistent level of indenting. Be sure you
398 line up everything on a given 'level' with the same number of indents.
399 Also, be sure not to use C<tab> characters (YAML does not support them
400 because they are handled inconsistently across editors).
403 =head2 Add Login and Logout Controllers
405 Use the Catalyst create script to create two stub controller files:
407 $ script/myapp_create.pl controller Login
408 $ script/myapp_create.pl controller Logout
410 B<NOTE>: You could easily use a single controller here. For example,
411 you could have a C<User> controller with both C<login> and C<logout>
412 actions. Remember, Catalyst is designed to be very flexible, and leaves
413 such matters up to you, the designer and programmer.
415 Then open C<lib/MyApp/Controller/Login.pm>, locate the C<sub index :
416 Private> method (this was automatically inserted by the helpers when we
417 created the Login controller above), and delete this line:
419 $c->response->body('Matched MyApp::Controller::Login in Login.');
421 Then update it to match:
429 sub index : Private {
432 # Get the username and password from form
433 my $username = $c->request->params->{username} || "";
434 my $password = $c->request->params->{password} || "";
436 # If the username and password values were found in form
437 if ($username && $password) {
438 # Attempt to log the user in
439 if ($c->login($username, $password)) {
440 # If successful, then let them use the application
441 $c->response->redirect($c->uri_for('/books/list'));
444 # Set an error message
445 $c->stash->{error_msg} = "Bad username or password.";
449 # If either of above don't work out, send to the login page
450 $c->stash->{template} = 'login.tt2';
453 This controller fetches the C<username> and C<password> values from the
454 login form and attempts to perform a login. If successful, it redirects
455 the user to the book list page. If the login fails, the user will stay
456 at the login page but receive an error message. If the C<username> and
457 C<password> values are not present in the form, the user will be taken
458 to the empty login form.
460 Note that we could have used something like C<sub default :Private>;
461 however, the use of C<default> actions is discouraged because it does
462 not receive path args as with other actions. The recommended practice
463 is to only use C<default> in C<MyApp::Controller::Root>.
465 Another option would be to use something like
466 C<sub base :Path :Args(0) {...}> (where the C<...> refers to the login
467 code shown in C<sub index : Private> above). We are using C<sub base
468 :Path :Args(0) {...}> here to specifically match the URL C</login>.
469 C<Path> actions (aka, "literal actions") create URI matches relative to
470 the namespace of the controller where they are defined. Although
471 C<Path> supports arguments that allow relative and absolute paths to be
472 defined, here we use an empty C<Path> definition to match on just the
473 name of the controller itself. The method name, C<base>, is arbitrary.
474 We make the match even more specific with the C<:Args(0)> action
475 modifier -- this forces the match on I<only> C</login>, not
476 C</login/somethingelse>.
478 Next, update the corresponding method in C<lib/MyApp/Controller/Logout.pm>
487 sub index : Private {
490 # Clear the user's state
493 # Send the user to the starting point
494 $c->response->redirect($c->uri_for('/'));
497 As with the login controller, be sure to delete the
498 C<$c->response->body('Matched MyApp::Controller::Logout in Logout.');>
499 line of the C<sub index>.
502 =head2 Add a Login Form TT Template Page
504 Create a login form by opening C<root/src/login.tt2> and inserting:
506 [% META title = 'Login' %]
509 <form method="post" action=" [% Catalyst.uri_for('/login') %] ">
513 <td><input type="text" name="username" size="40" /></td>
517 <td><input type="password" name="password" size="40" /></td>
520 <td colspan="2"><input type="submit" name="submit" value="Submit" /></td>
526 =head2 Add Valid User Check
528 We need something that provides enforcement for the authentication
529 mechanism -- a I<global> mechanism that prevents users who have not
530 passed authentication from reaching any pages except the login page.
531 This is generally done via an C<auto> action/method (prior to Catalyst
532 v5.66, this sort of thing would go in C<MyApp.pm>, but starting in
533 v5.66, the preferred location is C<lib/MyApp/Controller/Root.pm>).
535 Edit the existing C<lib/MyApp/Controller/Root.pm> class file and insert
536 the following method:
540 Check if there is a user and, if not, forward to login page
544 # Note that 'auto' runs after 'begin' but before your actions and that
545 # 'auto' "chain" (all from application path to most specific class are run)
546 # See the 'Actions' section of 'Catalyst::Manual::Intro' for more info.
550 # Allow unauthenticated users to reach the login page. This
551 # allows anauthenticated users to reach any action in the Login
552 # controller. To lock it down to a single action, we could use:
553 # if ($c->action eq $c->controller('Login')->action_for('index'))
554 # to only allow unauthenticated access to the C<index> action we
556 if ($c->controller eq $c->controller('Login')) {
560 # If a user doesn't exist, force login
561 if (!$c->user_exists) {
562 # Dump a log message to the development server debug output
563 $c->log->debug('***Root::auto User not found, forwarding to /login');
564 # Redirect the user to the login page
565 $c->response->redirect($c->uri_for('/login'));
566 # Return 0 to cancel 'post-auto' processing and prevent use of application
570 # User found, so return 1 to continue with processing after this 'auto'
574 B<Note:> Catalyst provides a number of different types of actions, such
575 as C<Local>, C<Regex>, and C<Private>. You should refer to
576 L<Catalyst::Manual::Intro> for a more detailed explanation, but the
577 following bullet points provide a quick introduction:
583 The majority of application use C<Local> actions for items that respond
584 to user requests and C<Private> actions for those that do not directly
585 respond to user input.
589 There are five types of C<Private> actions: C<begin>, C<end>,
590 C<default>, C<index>, and C<auto>.
594 With C<begin>, C<end>, C<default>, C<index> private actions, only the
595 most specific action of each type will be called. For example, if you
596 define a C<begin> action in your controller it will I<override> a
597 C<begin> action in your application/root controller -- I<only> the
598 action in your controller will be called.
602 Unlike the other actions where only a single method is called for each
603 request, I<every> auto action along the chain of namespaces will be
604 called. Each C<auto> action will be called I<from the application/root
605 controller down through the most specific class>.
609 By placing the authentication enforcement code inside the C<auto> method
610 of C<lib/MyApp/Controller/Root.pm> (or C<lib/MyApp.pm>), it will be
611 called for I<every> request that is received by the entire application.
614 =head2 Displaying Content Only to Authenticated Users
616 Let's say you want to provide some information on the login page that
617 changes depending on whether the user has authenticated yet. To do
618 this, open C<root/src/login.tt2> in your editor and add the following
619 lines to the bottom of the file:
623 # This code illustrates how certain parts of the TT
624 # template will only be shown to users who have logged in
626 [% IF Catalyst.user_exists %]
627 Please Note: You are already logged in as '[% Catalyst.user.username %]'.
628 You can <a href="[% Catalyst.uri_for('/logout') %]">logout</a> here.
630 You need to log in to use this application.
633 Note that this whole block is a comment because the "#" appears
634 immediate after the "[%" (with no spaces in between). Although it
635 can be a handy way to temporarily "comment out" a whole block of
636 TT code, it's probably a little too subtle for use in "normal"
641 Although most of the code is comments, the middle few lines provide a
642 "you are already logged in" reminder if the user returns to the login
643 page after they have already authenticated. For users who have not yet
644 authenticated, a "You need to log in..." message is displayed (note the
645 use of an IF-THEN-ELSE construct in TT).
648 =head2 Try Out Authentication
650 Press C<Ctrl-C> to kill the previous server instance (if it's still
651 running) and restart it:
653 $ script/myapp_server.pl
655 B<IMPORTANT NOTE>: If you happen to be using Internet Explorer, you may
656 need to use the command C<script/myapp_server.pl -k> to enable the
657 keepalive feature in the development server. Otherwise, the HTTP
658 redirect on successful login may not work correctly with IE (it seems to
659 work without -k if you are running the web browser and development
660 server on the same machine). If you are using browser a browser other
661 than IE, it should work either way. If you want to make keepalive the
662 default, you can edit C<script/myapp_server.pl> and change the
663 initialization value for C<$keepalive> to C<1>. (You will need to do
664 this every time you create a new Catalyst application or rebuild the
665 C<myapp_server.pl> script.)
667 Now trying going to L<http://localhost:3000/books/list> and you should
668 be redirected to the login page, hitting Shift+Reload if necessary (the
669 "You are already logged in" message should I<not> appear -- if it does,
670 click the C<logout> button and try again). Note the C<***Root::auto User
671 not found...> debug message in the development server output. Enter
672 username C<test01> and password C<mypass>, and you should be taken to
675 Open C<root/src/books/list.tt2> and add the following lines to the
679 <a href="[% Catalyst.uri_for('/login') %]">Login</a>
680 <a href="[% Catalyst.uri_for('form_create') %]">Create</a>
683 Reload your browser and you should now see a "Login" and "Create" links
684 at the bottom of the page (as mentioned earlier, you can update template
685 files without reloading the development server). Click the first link
686 to return to the login page. This time you I<should> see the "You are
687 already logged in" message.
689 Finally, click the C<You can logout here> link on the C</login> page.
690 You should stay at the login page, but the message should change to "You
691 need to log in to use this application."
694 =head1 USING PASSWORD HASHES
696 In this section we increase the security of our system by converting
697 from cleartext passwords to SHA-1 password hashes.
699 B<Note:> This section is optional. You can skip it and the rest of the
700 tutorial will function normally.
702 Note that even with the techniques shown in this section, the browser
703 still transmits the passwords in cleartext to your application. We are
704 just avoiding the I<storage> of cleartext passwords in the database by
705 using a SHA-1 hash. If you are concerned about cleartext passwords
706 between the browser and your application, consider using SSL/TLS, made
707 easy with the Catalyst plugin Catalyst::Plugin:RequireSSL.
710 =head2 Get a SHA-1 Hash for the Password
712 Catalyst uses the C<Digest> module to support a variety of hashing
713 algorithms. Here we will use SHA-1 (SHA = Secure Hash Algorithm).
714 First, we should compute the SHA-1 hash for the "mypass" password we are
715 using. The following command-line Perl script provides a "quick and
716 dirty" way to do this:
718 $ perl -MDigest::SHA -e 'print Digest::SHA::sha1_hex("mypass"), "\n"'
719 e727d1464ae12436e899a726da5b2f11d8381b26
722 B<Note:> You should probably modify this code for production use to
723 not read the password from the command line. By having the script
724 prompt for the cleartext password, it avoids having the password linger
725 in forms such as your C<.bash_history> files (assuming you are using
726 BASH as your shell). An example of such a script can be found in
730 =head2 Switch to SHA-1 Password Hashes in the Database
732 Next, we need to change the C<password> column of our C<users> table to
733 store this hash value vs. the existing cleartext password. Open
734 C<myapp03.sql> in your editor and enter:
737 -- Convert passwords to SHA-1 hashes
739 UPDATE users SET password = 'e727d1464ae12436e899a726da5b2f11d8381b26' WHERE id = 1;
740 UPDATE users SET password = 'e727d1464ae12436e899a726da5b2f11d8381b26' WHERE id = 2;
741 UPDATE users SET password = 'e727d1464ae12436e899a726da5b2f11d8381b26' WHERE id = 3;
743 Then use the following command to update the SQLite database:
745 $ sqlite3 myapp.db < myapp03.sql
747 B<Note:> We are using SHA-1 hashes here, but many other hashing
748 algorithms are supported. See C<Digest> for more information.
751 =head2 Enable SHA-1 Hash Passwords in
752 C<Catalyst::Plugin::Authentication::Store::DBIC>
754 Edit C<myapp.yml> and update it to match (the C<password_type> and
755 C<password_hash_type> are new, everything else is the same):
761 # Note this first definition would be the same as setting
762 # __PACKAGE__->config->{authentication}->{dbic}->{user_class} = 'MyAppDB::User'
763 # in lib/MyApp.pm (IOW, each hash key becomes a "name:" in the YAML file).
765 # This is the model object created by Catalyst::Model::DBIC from your
766 # schema (you created 'MyAppDB::User' but as the Catalyst startup
767 # debug messages show, it was loaded as 'MyApp::Model::MyAppDB::User').
768 # NOTE: Omit 'MyApp::Model' here just as you would when using
769 # '$c->model("MyAppDB::User)'
770 user_class: MyAppDB::User
771 # This is the name of the field in your 'users' table that contains the user's name
773 # This is the name of the field in your 'users' table that contains the password
774 password_field: password
775 # Other options can go here for hashed passwords
776 # Enabled hashed passwords
777 password_type: hashed
778 # Use the SHA-1 hashing algorithm
779 password_hash_type: SHA-1
782 =head2 Try Out the Hashed Passwords
784 Press C<Ctrl-C> to kill the previous server instance (if it's still
785 running) and restart it:
787 $ script/myapp_server.pl
789 You should now be able to go to L<http://localhost:3000/books/list> and
790 login as before. When done, click the "Logout" link on the login page
791 (or point your browser at L<http://localhost:3000/logout>).
793 B<Note:> If you receive the debug screen in your browser with a
794 C<Can't call method "stash" on an undefined value...> error message,
795 make sure that you are using v0.07 of
796 L<Catalyst::Plugin::Authorization::ACL|Catalyst::Plugin::Authorization::ACL>.
797 The following command can be a useful way to quickly dump the version number
798 of this module on your system:
800 perl -MCatalyst::Plugin::Authorization::ACL -e 'print $Catalyst::Plugin::Authorization::ACL::VERSION, "\n";'
803 =head1 USING THE SESSION FOR FLASH
805 As discussed in Part 3 of the tutorial, C<flash> allows you to set
806 variables in a way that is very similar to C<stash>, but it will
807 remain set across multiple requests. Once the value is read, it
808 is cleared (unless reset). Although C<flash> has nothing to do with
809 authentication, it does leverage the same session plugins. Now that
810 those plugins are enabled, let's go back and improve the "delete
811 and redirect with query parameters" code seen at the end of the
812 L<Basic CRUD|Catalyst::Manual::Tutorial::BasicCRUD> part of the
815 First, open C<lib/MyApp/Controller/Books.pm> and modify C<sub delete>
816 to match the following:
825 # $id = primary key of book to delete
826 my ($self, $c, $id) = @_;
828 # Search for the book and then delete it
829 $c->model('MyAppDB::Book')->search({id => $id})->delete_all;
831 # Use 'flash' to save information across requests until it's read
832 $c->flash->{status_msg} = "Book deleted";
834 # Redirect the user back to the list page with status msg as an arg
835 $c->response->redirect($c->uri_for('/books/list'));
838 Next, open C<root/lib/site/layout> and update the TT code to pull from
839 flash vs. the C<status_msg> query parameter:
841 <div id="header">[% PROCESS site/header %]</div>
844 <span class="message">[% status_msg || Catalyst.flash.status_msg %]</span>
845 <span class="error">[% error_msg %]</span>
849 <div id="footer">[% PROCESS site/footer %]</div>
854 Restart the development server and point your browser to
855 L<http://localhost:3000/books/url_create/Test/1/4> to create an extra
856 book. Click the "Return to list" link and delete the "Test" book you
857 just added. The C<flash> mechanism should retain our "Book deleted"
858 status message across the redirect.
860 B<NOTE:> While C<flash> will save information across multiple requests,
861 I<it does get cleared the first time it is read>. In general, this is
862 exactly what you want -- the C<flash> message will get displayed on
863 the next screen where it's appropriate, but it won't "keep showing up"
864 after that first time (unless you reset it). Please refer to
865 L<Catalyst::Plugin::Session|Catalyst::Plugin::Session> for additional
871 Kennedy Clark, C<hkclark@gmail.com>
873 Please report any errors, issues or suggestions to the author. The
874 most recent version of the Catalyst Tutorial can be found at
875 L<http://dev.catalyst.perl.org/repos/Catalyst/trunk/Catalyst-Manual/lib/Catalyst/Manual/Tutorial/>.
877 Copyright 2006, Kennedy Clark, under Creative Commons License
878 (L<http://creativecommons.org/licenses/by-nc-sa/2.5/>).