X-Git-Url: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?p=catagits%2FCatalyst-Manual.git;a=blobdiff_plain;f=lib%2FCatalyst%2FManual%2FTutorial%2FAuthentication.pod;h=7e002a88f1a5822a79a58bb2c4cc80942f469cbc;hp=fa577d312b735286e8c8daa913e8f9e31a07ddb8;hb=25ed8f404ffffd0d566e8f7240d63b8a9c17a4c9;hpb=3533daff0314522f79dff9c618da087568f1378c diff --git a/lib/Catalyst/Manual/Tutorial/Authentication.pod b/lib/Catalyst/Manual/Tutorial/Authentication.pod index fa577d3..7e002a8 100644 --- a/lib/Catalyst/Manual/Tutorial/Authentication.pod +++ b/lib/Catalyst/Manual/Tutorial/Authentication.pod @@ -125,8 +125,8 @@ 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: - $ script/myapp_create.pl model MyAppDB DBIC::Schema MyApp::Schema::MyAppDB create=static dbi:SQLite:myapp.db - $ ls lib/MyApp/Schema/MyAppDB + $ 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 Notice how the helper has added three new table-specific result source @@ -142,7 +142,7 @@ 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: +C: # # Set relationships: @@ -153,7 +153,7 @@ 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 => 'MyApp::Schema::MyAppDB::UserRoles', 'user_id'); + __PACKAGE__->has_many(map_user_role => 'MyApp::Schema::UserRoles', 'user_id'); # many_to_many(): # args: @@ -164,7 +164,7 @@ C: __PACKAGE__->many_to_many(roles => 'map_user_role', 'role'); -C: +C: # # Set relationships: @@ -175,10 +175,10 @@ 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 => 'MyApp::Schema::MyAppDB::UserRoles', 'role_id'); + __PACKAGE__->has_many(map_user_role => 'MyApp::Schema::UserRoles', 'role_id'); -C: +C: # # Set relationships: @@ -189,14 +189,14 @@ 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 => 'MyApp::Schema::MyAppDB::Users', '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 => 'MyApp::Schema::MyAppDB::Roles', 'role_id'); + __PACKAGE__->belongs_to(role => 'MyApp::Schema::Roles', 'role_id'); The code for these three sets of updates is obviously very similar to @@ -204,9 +204,9 @@ 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 +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 +C directory, so it will automatically pick up our new table information. @@ -227,13 +227,13 @@ 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::Books | class | - | MyApp::Model::MyAppDB::BookAuthors | class | - | MyApp::Model::MyAppDB::Roles | class | - | MyApp::Model::MyAppDB::Users | class | - | MyApp::Model::MyAppDB::UserRoles | 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 | '-------------------------------------------------------------------+----------' ... @@ -287,55 +287,63 @@ backed session store). 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 +information in C and automatically load this information into Cconfig> using the -L plugin. Here, we need -to load several parameters that tell +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: +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 - # (IOW, each hash key becomes a "name:" in the YAML file). # # Specify that we are going to do password-based auth - class: Password + class Password # This is the name of the field in the users table with the # password stored in it - password_field: password + password_field password # We are using an unencrypted password now - password_type: clear - store: + password_type clear + + # Use DBIC to retrieve username, password & role information - class: DBIx::Class + 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::Users'). + # 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("MyAppDB::Users)' - user_class: MyAppDB::Users + # '$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 + 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 B 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 @@ -344,7 +352,7 @@ 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. @@ -609,17 +617,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