X-Git-Url: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?a=blobdiff_plain;f=lib%2FCatalyst%2FManual%2FTutorial%2FAuthentication.pod;h=652d2107cdca39634a2e8896cae0529e91e87ff4;hb=14e5ed66dcd737f2210d8d7d8c22e3c474992846;hp=673a93dc12f4b1f93e3e5f246c213d74a5228904;hpb=6d0971ad6e54665ea8c239499e715a64fe1b83ca;p=catagits%2FCatalyst-Manual.git
diff --git a/lib/Catalyst/Manual/Tutorial/Authentication.pod b/lib/Catalyst/Manual/Tutorial/Authentication.pod
index 673a93d..652d210 100644
--- a/lib/Catalyst/Manual/Tutorial/Authentication.pod
+++ b/lib/Catalyst/Manual/Tutorial/Authentication.pod
@@ -1,11 +1,11 @@
=head1 NAME
-Catalyst::Manual::Tutorial::Authentication - Catalyst Tutorial - Part 4: Authentication
+Catalyst::Manual::Tutorial::Authentication - Catalyst Tutorial - Part 5: Authentication
=head1 OVERVIEW
-This is B for the Catalyst tutorial.
+This is B for the Catalyst tutorial.
L
@@ -21,30 +21,34 @@ L
=item 3
-L
+L
=item 4
-B
+L
=item 5
-L
+B
=item 6
-L
+L
=item 7
-L
+L
=item 8
-L
+L
=item 9
+L
+
+=item 10
+
L
=back
@@ -52,8 +56,8 @@ L
=head1 DESCRIPTION
-Now that we finally have a simple yet functional application, we can
-focus on providing authentication (with authorization coming next in
+Now that we finally have a simple yet functional application, we can
+focus on providing authentication (with authorization coming next in
Part 5).
This part of the tutorial is divided into two main sections: 1) basic,
@@ -117,58 +121,29 @@ Then load this into the C database with the following command:
=head2 Add User and Role Information to DBIC Schema
-This step adds DBIC-based classes for the user-related database tables
-(the role information will not be used until Part 5):
+Although we could manually edit the DBIC schema information to include
+the new tables added in the previous step, let's use the C
+option on the DBIC model helper to do most of the work for us:
-Edit C and update the contents to match (only the
-C [qw/Book BookAuthor Author User UserRole Role/]> line
-has changed):
+ $ script/myapp_create.pl model DB DBIC::Schema MyApp::Schema create=static dbi:SQLite:myapp.db
+ $ ls lib/MyApp/Schema
+ Authors.pm BookAuthors.pm Books.pm Roles.pm UserRoles.pm Users.pm
- package MyAppDB;
-
- =head1 NAME
-
- MyAppDB -- DBIC Schema Class
-
- =cut
-
- # Our schema needs to inherit from 'DBIx::Class::Schema'
- use base qw/DBIx::Class::Schema/;
-
- # Need to load the DB Model classes here.
- # You can use this syntax if you want:
- # __PACKAGE__->load_classes(qw/Book BookAuthor Author User UserRole Role/);
- # Also, if you simply want to load all of the classes in a directory
- # of the same name as your schema class (as we do here) you can use:
- # __PACKAGE__->load_classes(qw//);
- # But the variation below is more flexible in that it can be used to
- # load from multiple namespaces.
- __PACKAGE__->load_classes({
- MyAppDB => [qw/Book BookAuthor Author User UserRole Role/]
- });
-
- 1;
+Notice how the helper has added three new table-specific result source
+files to the C 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
+enhancements would have been preserved.
-=head2 Create New "Result Source Objects"
+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<#
+DO NOT MODIFY THIS OR ANYTHING ABOVE!> comment and the closing C<1;>:
-Create the following three files with the content shown below.
+C:
-C:
-
- package MyAppDB::User;
-
- use base qw/DBIx::Class/;
-
- # Load required DBIC stuff
- __PACKAGE__->load_components(qw/PK::Auto Core/);
- # Set the table name
- __PACKAGE__->table('users');
- # Set columns in table
- __PACKAGE__->add_columns(qw/id username password email_address first_name last_name/);
- # Set the primary key for the table
- __PACKAGE__->set_primary_key('id');
-
#
# Set relationships:
#
@@ -178,41 +153,19 @@ C:
# 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 => 'MyAppDB::UserRole', 'user_id');
-
-
- =head1 NAME
-
- MyAppDB::User - A model object representing a person with access to the system.
-
- =head1 DESCRIPTION
+ __PACKAGE__->has_many(map_user_role => 'MyApp::Schema::UserRoles', 'user_id');
- This is an object that represents a row in the 'users' table of your application
- database. It uses DBIx::Class (aka, DBIC) to do ORM.
-
- For Catalyst, this is designed to be used through MyApp::Model::MyAppDB.
- Offline utilities may wish to use this class directly.
-
- =cut
-
- 1;
+ # 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
+ # You must already have the has_many() defined to use a many_to_many().
+ __PACKAGE__->many_to_many(roles => 'map_user_role', 'role');
-C:
+C:
- package MyAppDB::Role;
-
- use base qw/DBIx::Class/;
-
- # Load required DBIC stuff
- __PACKAGE__->load_components(qw/PK::Auto Core/);
- # Set the table name
- __PACKAGE__->table('roles');
- # Set columns in table
- __PACKAGE__->add_columns(qw/id role/);
- # Set the primary key for the table
- __PACKAGE__->set_primary_key('id');
-
#
# Set relationships:
#
@@ -222,42 +175,11 @@ C:
# 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 => 'MyAppDB::UserRole', 'role_id');
-
-
- =head1 NAME
-
- MyAppDB::Role - A model object representing a class of access permissions to
- the system.
-
- =head1 DESCRIPTION
-
- This is an object that represents a row in the 'roles' table of your
- application database. It uses DBIx::Class (aka, DBIC) to do ORM.
-
- For Catalyst, this is designed to be used through MyApp::Model::MyAppDB.
- "Offline" utilities may wish to use this class directly.
-
- =cut
-
- 1;
+ __PACKAGE__->has_many(map_user_role => 'MyApp::Schema::UserRoles', 'role_id');
-C:
+C:
- package MyAppDB::UserRole;
-
- use base qw/DBIx::Class/;
-
- # Load required DBIC stuff
- __PACKAGE__->load_components(qw/PK::Auto Core/);
- # Set the table name
- __PACKAGE__->table('user_roles');
- # Set columns in table
- __PACKAGE__->add_columns(qw/user_id role_id/);
- # Set the primary key for the table
- __PACKAGE__->set_primary_key(qw/user_id role_id/);
-
#
# Set relationships:
#
@@ -267,41 +189,33 @@ C:
# 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 => 'MyAppDB::User', 'user_id');
+ __PACKAGE__->belongs_to(user => 'MyApp::Schema::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 => 'MyAppDB::Role', 'role_id');
-
-
- =head1 NAME
-
- MyAppDB::UserRole - A model object representing the JOIN between Users and Roles.
-
- =head1 DESCRIPTION
-
- This is an object that represents a row in the 'user_roles' table of your application
- database. It uses DBIx::Class (aka, DBIC) to do ORM.
-
- You probably won't need to use this class directly -- it will be automatically
- used by DBIC where joins are needed.
-
- For Catalyst, this is designed to be used through MyApp::Model::MyAppDB.
- Offline utilities may wish to use this class directly.
-
- =cut
-
- 1;
+ __PACKAGE__->belongs_to(role => 'MyApp::Schema::Roles', 'role_id');
+
-The code for these three result source classes is obviously very familiar to the C, C, and C classes created in Part 2.
+The code for these three sets of updates is obviously very similar to
+the edits we made to the C, C, and C
+classes created in Part 3.
+
+Note that we do not need to make any change to the
+C schema file. It simple tells DBIC to
+load all of the result source files it finds in below the
+C 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 to kill the previous server instance (if it's still running) and restart it:
+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 to kill the previous server instance (if it's still running)
+and restart it:
$ script/myapp_server.pl
@@ -313,23 +227,25 @@ Look for the three new model objects in the startup debug output:
+-------------------------------------------------------------------+----------+
| MyApp::Controller::Books | instance |
| MyApp::Controller::Root | instance |
- | MyApp::Model::MyAppDB | instance |
- | MyApp::Model::MyAppDB::Author | class |
- | MyApp::Model::MyAppDB::Book | class |
- | MyApp::Model::MyAppDB::BookAuthor | class |
- | MyApp::Model::MyAppDB::Role | class |
- | MyApp::Model::MyAppDB::User | class |
- | MyApp::Model::MyAppDB::UserRole | class |
+ | MyApp::Model::DB | instance |
+ | MyApp::Model::DB::Author | class |
+ | MyApp::Model::DB::Books | class |
+ | MyApp::Model::DB::BookAuthors | class |
+ | MyApp::Model::DB::Roles | class |
+ | MyApp::Model::DB::Users | class |
+ | MyApp::Model::DB::UserRoles | class |
| MyApp::View::TT | instance |
'-------------------------------------------------------------------+----------'
...
-Again, notice that your "result source" classes have been "re-loaded" by Catalyst under C.
+Again, notice that your "result source" classes have been "re-loaded"
+by Catalyst under C.
=head2 Include Authentication and Session Plugins
-Edit C and update it as follows (everything below C is new):
+Edit C and update it as follows (everything below
+C is new):
use Catalyst qw/
-Debug
@@ -345,71 +261,89 @@ Edit C and update it as follows (everything below C is
Session::State::Cookie
/;
-The C plugin supports
-Authentication while the C plugins are required to maintain
-state across multiple HTTP requests.
+The C plugin supports Authentication while the
+C 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 occured in version 0.09999_01
-of the C plugin. You B to specify a
-particular Authentication::Store or Authentication::Credential plugin.
-Instead, indicate the Store and Credential you want to use in your application
+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 plugin. You B 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
-(L
-is generally a good choice if you are on Unix; try
-L if you
-are on Win32) -- consult
-L and its subclasses
-for additional information and options (for example to use a
-database-backed session store).
+Note that there are several options for
+L
+(L
+is generally a good choice if you are on Unix; try
+L if you
+are on Win32) -- consult
+L and its subclasses
+for additional information and options (for example to use a database-
+backed session store).
=head2 Configure Authentication
-Although C<__PACKAGE__-Econfig(name =E 'value');> is still
-supported, newer Catalyst applications tend to place all configuration
-information in C and automatically load this information into
-Cconfig> using the
-L plugin. Here, we need
-to load several parameters that tell
-L
+Although C<__PACKAGE__-Econfig(name =E 'value');> is still
+supported, newer Catalyst applications tend to place all configuration
+information in C and automatically load this information
+into Cconfig> using the
+L plugin.
+
+First, as noted in Part 3 of the tutorial, Catalyst has recently
+switched from a default config file format of YAML to
+C (an apache-like format). In case you are using
+a version of Catalyst earlier than v5.7014, delete the C
+file and simply follow the directions below to create a new
+C file.
+
+Here, we need to load several parameters that tell
+L
where to locate information in your database. To do this, edit the
-C YAML and update it to match:
-
- ---
- name: MyApp
- authentication:
- default_realm: dbic
- realms:
- dbic:
- credential:
- class: Password
- password_field: password
- password_type: self_check
- store:
- class: DBIx::Class
- # This is the model object created by Catalyst::Model::DBIC from your
- # schema (you created 'MyAppDB::User' but as the Catalyst startup
- # debug messages show, it was loaded as 'MyApp::Model::MyAppDB::User').
- # NOTE: Omit 'MyApp::Model' to avoid a component lookup issue in Catalyst 5.66
- user_class: MyApp::Users
- # This is the name of the field in your 'users' table that contains the user's name
- id_field: username
- role_relation: roles
- role_field: rolename
- ignore_fields_in_find: [ 'remote_name' ]
+C file and update it to match:
+
+ name MyApp
+
+ default_realm dbic
+
+
+
+ # 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
+
+
+ # 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
+
+
+
+
Inline comments in the code above explain how each field is being used.
-B: Although YAML uses a very simple and easy-to-ready format, it
-does require the use of a consistent level of indenting. Be sure you
-line up everything on a given 'level' with the same number of indents.
-Also, be sure not to use C characters (YAML does not support them
-because they are handled inconsistently across editors).
-
+Note that you can use many other config file formats with catalyst.
+See L
+for details.
=head2 Add Login and Logout Controllers
@@ -418,14 +352,16 @@ Use the Catalyst create script to create two stub controller files:
$ script/myapp_create.pl controller Login
$ script/myapp_create.pl controller Logout
-B: You could easily use a single controller here. For example,
+B You could easily use a single controller here. For example,
you could have a C controller with both C and C
actions. Remember, Catalyst is designed to be very flexible, and leaves
such matters up to you, the designer and programmer.
-Then open C, locate the C method (this was automatically inserted by the helpers when we
-created the Login controller above), and delete this line:
+Then open C, locate the C method (or C 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:
$c->response->body('Matched MyApp::Controller::Login in Login.');
@@ -437,7 +373,7 @@ Then update it to match:
=cut
- sub index : Private {
+ sub index :Path :Args(0) {
my ($self, $c) = @_;
# Get the username and password from form
@@ -447,7 +383,8 @@ Then update it to match:
# If the username and password values were found in form
if ($username && $password) {
# Attempt to log the user in
- if ($c->login($username, $password)) {
+ if ($c->authenticate({ username => $username,
+ password => $password} )) {
# If successful, then let them use the application
$c->response->redirect($c->uri_for('/books/list'));
return;
@@ -462,32 +399,31 @@ Then update it to match:
}
This controller fetches the C and C values from the
-login form and attempts to perform a login. 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 and
-C 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;
-however, the use of C actions is discouraged because it does
-not receive path args as with other actions. The recommended practice
-is to only use C in C.
-
-Another option would be to use something like
-C (where the C<...> refers to the login
-code shown in C above). We are using C here to specifically match the URL C.
-C actions (aka, "literal actions") create URI matches relative to
-the namespace of the controller where they are defined. Although
-C supports arguments that allow relative and absolute paths to be
-defined, here we use an empty C definition to match on just the
-name of the controller itself. The method name, C, is arbitrary.
-We make the match even more specific with the C<:Args(0)> action
-modifier -- this forces the match on I C, not
+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 and C 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,
+however partly for historical reasons, and partly for code clarity it
+is generally recommended only to use C in
+C, and then mainly to generate the 404 not
+found page for the application.
+
+Instead, we are using C here to
+specifically match the URL C. C actions (aka, "literal
+actions") create URI matches relative to the namespace of the
+controller where they are defined. Although C supports
+arguments that allow relative and absolute paths to be defined, here
+we use an empty C definition to match on just the name of the
+controller itself. The method name, C, is arbitrary. We make
+the match even more specific with the C<:Args(0)> action modifier --
+this forces the match on I C, not
C.
-Next, update the corresponding method in C
-to match:
+Next, update the corresponding method in
+C to match:
=head2 index
@@ -495,7 +431,7 @@ to match:
=cut
- sub index : Private {
+ sub index :Path :Args(0) {
my ($self, $c) = @_;
# Clear the user's state
@@ -506,7 +442,7 @@ to match:
}
As with the login controller, be sure to delete the
-C<$c->response->body('Matched MyApp::Controller::Logout in Logout.');>
+C<$c-Eresponse-Ebody('Matched MyApp::Controller::Logout in Logout.');>
line of the C.
@@ -582,22 +518,41 @@ the following method:
return 1;
}
-B Catalyst provides a number of different types of actions, such
-as C, C, and C. You should refer to
-L for a more detailed explanation, but the
-following bullet points provide a quick introduction:
+
+B Catalyst provides a number of different types of actions,
+such as C, C, C and the new C. You
+should refer to L for
+a more detailed explanation, but the following bullet points provide a
+quick introduction:
=over 4
=item *
-The majority of application use C actions for items that respond
-to user requests and C actions for those that do not directly
-respond to user input.
+The majority of application have traditionally use C actions
+for items that respond to user requests and C actions for
+those that do not directly respond to user input.
=item *
-There are five types of C actions: C, C,
+Newer Catalyst applications tend to use C actions and the
+C 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. For example C in
+C would match on the URL
+C but C would
+match on C.
+
+=item *
+
+Automatic "chaining" of actions by the dispatcher is a powerful
+feature that allows multiple methods to handle a single URL. See
+L
+for more information on chained actions.
+
+=item *
+
+There are five types of build-in C actions: C, C,
C, C, and C.
=item *
@@ -647,7 +602,7 @@ lines to the bottom of the file:
TT code, it's probably a little too subtle for use in "normal"
comments.
%]
-
+
Although most of the code is comments, the middle few lines provide a
"you are already logged in" reminder if the user returns to the login
@@ -663,17 +618,13 @@ running) and restart it:
$ script/myapp_server.pl
-B: If you happen to be using Internet Explorer, you may
-need to use the command C