[Catalyst-commits] r13091 - in Catalyst-Authentication-Store-DBIx-Class/trunk: lib/Catalyst/Authentication/Realm lib/Catalyst/Authentication/Store/DBIx lib/Catalyst/Authentication/Store/DBIx/Class t

rafl at dev.catalyst.perl.org rafl at dev.catalyst.perl.org
Mon Mar 29 00:25:41 GMT 2010


Author: rafl
Date: 2010-03-29 01:25:41 +0100 (Mon, 29 Mar 2010)
New Revision: 13091

Removed:
   Catalyst-Authentication-Store-DBIx-Class/trunk/t/auth.db
Modified:
   Catalyst-Authentication-Store-DBIx-Class/trunk/lib/Catalyst/Authentication/Realm/SimpleDB.pm
   Catalyst-Authentication-Store-DBIx-Class/trunk/lib/Catalyst/Authentication/Store/DBIx/Class.pm
   Catalyst-Authentication-Store-DBIx-Class/trunk/lib/Catalyst/Authentication/Store/DBIx/Class/User.pm
Log:
Trim trailing whitespace.

Modified: Catalyst-Authentication-Store-DBIx-Class/trunk/lib/Catalyst/Authentication/Realm/SimpleDB.pm
===================================================================
--- Catalyst-Authentication-Store-DBIx-Class/trunk/lib/Catalyst/Authentication/Realm/SimpleDB.pm	2010-03-29 00:17:53 UTC (rev 13090)
+++ Catalyst-Authentication-Store-DBIx-Class/trunk/lib/Catalyst/Authentication/Realm/SimpleDB.pm	2010-03-29 00:25:41 UTC (rev 13091)
@@ -7,7 +7,7 @@
 
 sub new {
     my ($class, $realmname, $config, $app) = @_;
-    
+
     my $newconfig = {
         credential => {
             class => 'Password',
@@ -20,19 +20,19 @@
             use_userdata_from_session => '1'
         }
     };
-    
+
     if (!defined($config->{'user_model'})) {
 	    Catalyst::Exception->throw("Unable to initialize authentication, no user_model specified in SimpleDB config.");
    	}
 
-    
-    ## load any overrides for the credential 
+
+    ## load any overrides for the credential
     foreach my $key (qw/ password_type password_field password_hash_type/) {
         if (exists($config->{$key})) {
             $newconfig->{credential}{$key} = $config->{$key};
         }
-    } 
-    
+    }
+
     ## load any overrides for the store
     foreach my $key (qw/ user_model role_relation role_field role_column use_userdata_from_session/) {
         if (exists($config->{$key})) {
@@ -43,7 +43,7 @@
         delete $newconfig->{'store'}{'role_relation'};
         delete $newconfig->{'store'}{'role_field'};
     }
-    
+
     return $class->SUPER::new($realmname, $newconfig, $app);
 }
 
@@ -60,8 +60,8 @@
         Authentication
     /;
 
-    __PACKAGE__->config->{'Plugin::Authentication'} = 
-        {  
+    __PACKAGE__->config->{'Plugin::Authentication'} =
+        {
             default => {
                 class      => 'SimpleDB',
                 user_model => 'MyApp::Schema::Users',
@@ -69,17 +69,17 @@
         }
 
     # later on ...
-    $c->authenticate({ username => 'myusername', 
+    $c->authenticate({ username => 'myusername',
                        password => 'mypassword' });
 
     my $age = $c->user->get('age');
 
-    $c->logout;            
+    $c->logout;
 
 
 =head1 DESCRIPTION
 
-The Catalyst::Authentication::Realm::SimpleDB provides a simple way to configure Catalyst Authentication 
+The Catalyst::Authentication::Realm::SimpleDB provides a simple way to configure Catalyst Authentication
 when using the most common configuration of a password protected user retrieved from an SQL database.
 
 =head1 CONFIGURATION
@@ -116,17 +116,17 @@
 L<Catalyst::Authentication::Credential::Password> and
 L<Catalyst::Authentication::Store::DBIx::Class>.
 
-=over 
+=over
 
 =item user_model
 
 Contains the class name (as passed to $c->model() ) of the DBIx::Class schema
 to use as the source for user information.  This config item is B<REQUIRED>.
 
-=item password_field 
+=item password_field
 
 If your password field is not 'password' set this option to the name of your password field.  Note that if you change this
-to, say 'users_password' you will need to use that in the authenticate call:  
+to, say 'users_password' you will need to use that in the authenticate call:
 
     $c->authenticate({ username => 'bob', users_password => 'foo' });
 
@@ -134,27 +134,27 @@
 
 If the password is not stored in plaintext you will need to define what format the password is in.  The common options are
 B<crypted> and B<hashed>.  Crypted uses the standard unix crypt to encrypt the password.  Hashed uses the L<Digest> modules to
-perform password hashing.  
+perform password hashing.
 
 =item password_hash_type
 
-If you use a hashed password type - this defines the type of hashing. See L<Catalyst::Authentication::Credential::Password> 
-for more details on this setting.  
+If you use a hashed password type - this defines the type of hashing. See L<Catalyst::Authentication::Credential::Password>
+for more details on this setting.
 
 =item role_column
 
-If your users roles are stored directly in your user table, set this to the column name that contains your roles.  For 
-example, if your user table contains a field called 'permissions', the value of role_column would be 'permissions'. 
-B<NOTE>: If multiple values are stored in the role column, they should be space or pipe delimited. 
+If your users roles are stored directly in your user table, set this to the column name that contains your roles.  For
+example, if your user table contains a field called 'permissions', the value of role_column would be 'permissions'.
+B<NOTE>: If multiple values are stored in the role column, they should be space or pipe delimited.
 
 =item role_relation and role_field
 
-These define an alternate role relationship name and the column that holds the role's name in plain text.  See 
+These define an alternate role relationship name and the column that holds the role's name in plain text.  See
 L<Catalyst::Authentication::Store::DBIx::Class/CONFIGURATION> for more details on these settings.
 
 =item use_userdata_from_session
 
-This is a simple 1 / 0 setting which determines how a user's data is saved / restored from the session.  If 
+This is a simple 1 / 0 setting which determines how a user's data is saved / restored from the session.  If
 it is set to 1, the user's complete information (at the time of authentication) is cached between requests.
 If it is set to 0, the users information is loaded from the database on each request.
 
@@ -205,15 +205,15 @@
 
     __PACKAGE__->belongs_to(role => 'MyApp::Schema::Roles', 'role_id');
 
-=head1 MIGRATION 
+=head1 MIGRATION
 
 If and when your application becomes complex enough that you need more features
 than SimpleDB gives you access to, you can migrate to a standard Catalyst
 Authentication configuration fairly easily.  SimpleDB simply creates a standard
 Auth config based on the inputs you give it.  The config SimpleDB creates by default
-looks like this:  
+looks like this:
 
-    MyApp->config('Plugin::Authentication') = { 
+    MyApp->config('Plugin::Authentication') = {
         default => {
             credential => {
                 class => 'Password',
@@ -227,7 +227,7 @@
                 user_model => $user_model_from_simpledb_config
 	        }
 	    }
-    }; 
+    };
 
 
 =head1 SEE ALSO
@@ -235,9 +235,9 @@
 This module relies on a number of other modules to do it's job.  For more information
 you can refer to the following:
 
-=over 
+=over
 
-=item * 
+=item *
 L<Catalyst::Manual::Tutorial::Authentication>
 
 =item *

Modified: Catalyst-Authentication-Store-DBIx-Class/trunk/lib/Catalyst/Authentication/Store/DBIx/Class/User.pm
===================================================================
--- Catalyst-Authentication-Store-DBIx-Class/trunk/lib/Catalyst/Authentication/Store/DBIx/Class/User.pm	2010-03-29 00:17:53 UTC (rev 13090)
+++ Catalyst-Authentication-Store-DBIx-Class/trunk/lib/Catalyst/Authentication/Store/DBIx/Class/User.pm	2010-03-29 00:25:41 UTC (rev 13091)
@@ -22,11 +22,11 @@
         _roles => undef,
         _user => undef
     };
-    
+
     bless $self, $class;
 
-    
 
+
     if (not $self->{'resultset'}) {
         Catalyst::Exception->throw("\$c->model('${ \$self->config->{user_model} }') did not return a resultset. Did you set user_model correctly?");
     }
@@ -44,17 +44,17 @@
     if (!$self->{'resultset'}->result_source->has_column($self->config->{'id_field'})) {
         Catalyst::Exception->throw("id_field set to " .  $self->config->{'id_field'} . " but user table has no column by that name!");
     }
-    
+
     ## if we have lazyloading turned on - we should not query the DB unless something gets read.
     ## that's the idea anyway - still have to work out how to manage that - so for now we always force
     ## lazyload to off.
     $self->config->{lazyload} = 0;
-    
+
 #    if (!$self->config->{lazyload}) {
 #        return $self->load_user($authinfo, $c);
 #    } else {
 #        ## what do we do with a lazyload?
-#        ## presumably this is coming out of session storage.  
+#        ## presumably this is coming out of session storage.
 #        ## use $authinfo to fill in the user in that case?
 #    }
 
@@ -64,26 +64,26 @@
 
 sub load {
     my ($self, $authinfo, $c) = @_;
-    
+
     my $dbix_class_config = 0;
-    
+
     if (exists($authinfo->{'dbix_class'})) {
         $authinfo = $authinfo->{'dbix_class'};
         $dbix_class_config = 1;
     }
-    
+
     ## User can provide an arrayref containing the arguments to search on the user class.
     ## or even provide a prepared resultset, allowing maximum flexibility for user retreival.
-    ## these options are only available when using the dbix_class authinfo hash. 
+    ## these options are only available when using the dbix_class authinfo hash.
     if ($dbix_class_config && exists($authinfo->{'resultset'})) {
         $self->_user($authinfo->{'resultset'}->first);
     } elsif ($dbix_class_config && exists($authinfo->{'searchargs'})) {
-        $self->_user($self->resultset->search(@{$authinfo->{'searchargs'}})->first);    
+        $self->_user($self->resultset->search(@{$authinfo->{'searchargs'}})->first);
     } else {
         ## merge the ignore fields array into a hash - so we can do an easy check while building the query
-        my %ignorefields = map { $_ => 1} @{$self->config->{'ignore_fields_in_find'}};                                    
+        my %ignorefields = map { $_ => 1} @{$self->config->{'ignore_fields_in_find'}};
         my $searchargs = {};
-        
+
         # now we walk all the fields passed in, and build up a search hash.
         foreach my $key (grep {!$ignorefields{$_}} keys %{$authinfo}) {
             if ($self->resultset->result_source->has_column($key)) {
@@ -123,11 +123,11 @@
     if (ref $self->_roles eq 'ARRAY') {
         return(@{$self->_roles});
     }
-    
+
     my @roles = ();
     if (exists($self->config->{'role_column'})) {
         my $role_data = $self->get($self->config->{'role_column'});
-        if ($role_data) { 
+        if ($role_data) {
             @roles = split /[\s,\|]+/, $self->get($self->config->{'role_column'});
         }
         $self->_roles(\@roles);
@@ -148,28 +148,28 @@
 
 sub for_session {
     my $self = shift;
-    
+
     #return $self->get($self->config->{'id_field'});
-    
+
     #my $frozenuser = $self->_user->result_source->schema->freeze( $self->_user );
     #return $frozenuser;
-    
+
     my %userdata = $self->_user->get_columns();
     return \%userdata;
 }
 
 sub from_session {
     my ($self, $frozenuser, $c) = @_;
-    
+
     #my $obj = $self->resultset->result_source->schema->thaw( $frozenuser );
     #$self->_user($obj);
-    
+
     #if (!exists($self->config->{'use_userdata_from_session'}) || $self->config->{'use_userdata_from_session'} == 0) {
 #        $self->_user->discard_changes();
 #    }
-#    
+#
 #    return $self;
-#    
+#
 ## if use_userdata_from_session is defined in the config, we fill in the user data from the session.
     if (exists($self->config->{'use_userdata_from_session'}) && $self->config->{'use_userdata_from_session'} != 0)
     {
@@ -190,7 +190,7 @@
 
 sub get {
     my ($self, $field) = @_;
-    
+
     if ($self->_user->can($field)) {
         return $self->_user->$field;
     } else {
@@ -200,7 +200,7 @@
 
 sub get_object {
     my ($self, $force) = @_;
-    
+
     if ($force) {
         $self->_user->discard_changes;
     }
@@ -210,7 +210,7 @@
 
 sub obj {
     my ($self, $force) = @_;
-    
+
     return $self->get_object($force);
 }
 
@@ -253,8 +253,8 @@
 use this module. If you need more information than is present there, read the
 source.
 
-                
 
+
 =head1 DESCRIPTION
 
 The Catalyst::Authentication::Store::DBIx::Class::User class implements user storage
@@ -262,11 +262,11 @@
 
 =head1 SUBROUTINES / METHODS
 
-=head2 new 
+=head2 new
 
 Constructor.
 
-=head2 load ( $authinfo, $c ) 
+=head2 load ( $authinfo, $c )
 
 Retrieves a user from storage using the information provided in $authinfo.
 
@@ -280,18 +280,18 @@
 
 =head2 for_session
 
-Returns a serialized user for storage in the session.  
+Returns a serialized user for storage in the session.
 
 =head2 from_session
 
-Revives a serialized user from storage in the session. 
+Revives a serialized user from storage in the session.
 
 =head2 get ( $fieldname )
 
-Returns the value of $fieldname for the user in question.  Roughly translates to a call to 
+Returns the value of $fieldname for the user in question.  Roughly translates to a call to
 the DBIx::Class::Row's get_column( $fieldname ) routine.
 
-=head2 get_object 
+=head2 get_object
 
 Retrieves the DBIx::Class object that corresponds to this user
 
@@ -301,8 +301,8 @@
 
 =head2 auto_create
 
-This is called when the auto_create_user option is turned on in 
-Catalyst::Plugin::Authentication and a user matching the authinfo provided is not found. 
+This is called when the auto_create_user option is turned on in
+Catalyst::Plugin::Authentication and a user matching the authinfo provided is not found.
 By default, this will call the C<auto_create()> method of the resultset associated
 with this object. It is up to you to implement that method.
 

Modified: Catalyst-Authentication-Store-DBIx-Class/trunk/lib/Catalyst/Authentication/Store/DBIx/Class.pm
===================================================================
--- Catalyst-Authentication-Store-DBIx-Class/trunk/lib/Catalyst/Authentication/Store/DBIx/Class.pm	2010-03-29 00:17:53 UTC (rev 13090)
+++ Catalyst-Authentication-Store-DBIx-Class/trunk/lib/Catalyst/Authentication/Store/DBIx/Class.pm	2010-03-29 00:25:41 UTC (rev 13091)
@@ -15,16 +15,16 @@
 sub new {
     my ( $class, $config, $app ) = @_;
 
-    ## figure out if we are overriding the default store user class 
+    ## figure out if we are overriding the default store user class
     $config->{'store_user_class'} = (exists($config->{'store_user_class'})) ? $config->{'store_user_class'} :
                                         "Catalyst::Authentication::Store::DBIx::Class::User";
 
     ## make sure the store class is loaded.
     Catalyst::Utils::ensure_class_loaded( $config->{'store_user_class'} );
-    
+
     ## fields can be specified to be ignored during user location.  This allows
     ## the store to ignore certain fields in the authinfo hash.
-    
+
     $config->{'ignore_fields_in_find'} ||= [ ];
 
     my $self = {
@@ -39,7 +39,7 @@
 ## let's use DBIC's get_columns method to return a hash and save / restore that
 ## from the session.  Then we can respond to get() calls, etc. in most cases without
 ## resorting to a DB call.  If user_object is called, THEN we can hit the DB and
-## return a real object.  
+## return a real object.
 sub from_session {
     my ( $self, $c, $frozenuser ) = @_;
 
@@ -51,13 +51,13 @@
 
 sub for_session {
     my ($self, $c, $user) = @_;
-    
+
     return $user->for_session($c);
 }
 
 sub find_user {
     my ( $self, $authinfo, $c ) = @_;
-    
+
     my $user = $self->config->{'store_user_class'}->new($self->{'config'}, $c);
 
     return $user->load($authinfo, $c);
@@ -100,8 +100,8 @@
                     Authentication
                     Authorization::Roles/;
 
-    __PACKAGE__->config->{authentication} = 
-                    {  
+    __PACKAGE__->config->{authentication} =
+                    {
                         default_realm => 'members',
                         realms => {
                             members => {
@@ -114,33 +114,33 @@
                                     class => 'DBIx::Class',
             	                    user_model => 'MyApp::User',
             	                    role_relation => 'roles',
-            	                    role_field => 'rolename',	                
+            	                    role_field => 'rolename',
             	                }
                             }
                     	}
                     };
 
     # Log a user in:
-    
+
     sub login : Global {
         my ( $self, $c ) = @_;
-        
-        $c->authenticate({  
+
+        $c->authenticate({
                           screen_name => $c->req->params->username,
                           password => $c->req->params->password,
                           status => [ 'registered', 'loggedin', 'active']
                           }))
     }
-    
-    # verify a role 
-    
+
+    # verify a role
+
     if ( $c->check_user_roles( 'editor' ) ) {
         # do editor stuff
     }
-    
+
 =head1 DESCRIPTION
 
-The Catalyst::Authentication::Store::DBIx::Class class provides 
+The Catalyst::Authentication::Store::DBIx::Class class provides
 access to authentication information stored in a database via DBIx::Class.
 
 =head1 CONFIGURATION
@@ -154,8 +154,8 @@
 The DBIx::Class storage module has several configuration options
 
 
-    __PACKAGE__->config->{authentication} = 
-                    {  
+    __PACKAGE__->config->{authentication} =
+                    {
                         default_realm => 'members',
                         realms => {
                             members => {
@@ -168,7 +168,7 @@
             	                    role_relation => 'roles',
             	                    role_field => 'rolename',
             	                    ignore_fields_in_find => [ 'remote_name' ],
-            	                    use_userdata_from_session => 1,          
+            	                    use_userdata_from_session => 1,
             	                }
                 	        }
                     	}
@@ -186,7 +186,7 @@
 Contains the model name (as passed to $c->model()) of the DBIx::Class schema
 to use as the source for user information. This config item is B<REQUIRED>.
 
-(Note that this option used to be called C<< user_class >>. C<< user_class >> is 
+(Note that this option used to be called C<< user_class >>. C<< user_class >> is
 still functional, but should be used only for compatibility with previous configs.
 The setting called C<< user_class >> on other authentication stores is
 present, but named C<< store_user_class >> in this store)
@@ -196,21 +196,21 @@
 If your role information is stored in the same table as the rest of your user
 information, this item tells the module which field contains your role
 information.  The DBIx::Class authentication store expects the data in this
-field to be a series of role names separated by some combination of spaces, 
-commas, or pipe characters.  
+field to be a series of role names separated by some combination of spaces,
+commas, or pipe characters.
 
 =item role_relation
 
 If your role information is stored in a separate table, this is the name of
-the relation that will lead to the roles the user is in.  If this is 
+the relation that will lead to the roles the user is in.  If this is
 specified, then a role_field is also required.  Also when using this method
-it is expected that your role table will return one row for each role 
+it is expected that your role table will return one row for each role
 the user is in.
 
 =item role_field
 
-This is the name of the field in the role table that contains the string 
-identifying the role.  
+This is the name of the field in the role table that contains the string
+identifying the role.
 
 =item ignore_fields_in_find
 
@@ -223,64 +223,64 @@
 
 =item use_userdata_from_session
 
-Under normal circumstances, on each request the user's data is re-retrieved 
-from the database using the primary key for the user table.  When this flag 
+Under normal circumstances, on each request the user's data is re-retrieved
+from the database using the primary key for the user table.  When this flag
 is set in the configuration, it causes the DBIx::Class store to avoid this
-database hit on session restore.  Instead, the user object's column data 
-is retrieved from the session and used as-is.  
+database hit on session restore.  Instead, the user object's column data
+is retrieved from the session and used as-is.
 
 B<NOTE>: Since the user object's column
-data is only stored in the session during the initial authentication of 
+data is only stored in the session during the initial authentication of
 the user, turning this on can potentially lead to a situation where the data
 in $c->user is different from what is stored the database.  You can force
 a reload of the data from the database at any time by calling $c->user->get_object(1);
-Note that this will update $c->user for the remainder of this request.  
+Note that this will update $c->user for the remainder of this request.
 It will NOT update the session.  If you need to update the session
-you should call $c->update_user_in_session() as well.  
+you should call $c->update_user_in_session() as well.
 
 =item store_user_class
 
-This allows you to override the authentication user class that the 
+This allows you to override the authentication user class that the
 DBIx::Class store module uses to perform its work.  Most of the
-work done in this module is actually done by the user class, 
+work done in this module is actually done by the user class,
 L<Catalyst::Authentication::Store::DBIx::Class::User>, so
 overriding this doesn't make much sense unless you are using your
-own class to extend the functionality of the existing class.  
+own class to extend the functionality of the existing class.
 Chances are you do not want to set this.
 
 =item id_field
 
 In most cases, this config variable does not need to be set, as
 Catalyst::Authentication::Store::DBIx::Class will determine the primary
-key of the user table on its own.  If you need to override the default, 
+key of the user table on its own.  If you need to override the default,
 or your user table has multiple primary keys, then id_field
 should contain the column name that should be used to restore the user.
 A given value in this column should correspond to a single user in the database.
-Note that this is used B<ONLY> when restoring a user from the session and 
+Note that this is used B<ONLY> when restoring a user from the session and
 has no bearing whatsoever in the initial authentication process.  Note also
 that if use_userdata_from_session is enabled, this config parameter
 is not used at all.
 
 =back
 
-=head1 USAGE 
+=head1 USAGE
 
 The L<Catalyst::Authentication::Store::DBIx::Class> storage module
-is not called directly from application code.  You interface with it 
-through the $c->authenticate() call.  
+is not called directly from application code.  You interface with it
+through the $c->authenticate() call.
 
 There are three methods you can use to retrieve information from the DBIx::Class
 storage module.  They are Simple retrieval, and the advanced retrieval methods
 Searchargs and Resultset.
 
-=head2 Simple Retrieval 
+=head2 Simple Retrieval
 
 The first, and most common, method is simple retrieval. As its name implies
 simple retrieval allows you to simply to provide the column => value pairs
 that should be used to locate the user in question. An example of this usage
 is below:
 
-    if ($c->authenticate({  
+    if ($c->authenticate({
                           screen_name => $c->req->params->{'username'},
                           password => $c->req->params->{'password'},
                           status => [ 'registered', 'active', 'loggedin']
@@ -289,7 +289,7 @@
         # ... authenticated user code here
     }
 
-The above example would attempt to retrieve a user whose username column (here, 
+The above example would attempt to retrieve a user whose username column (here,
 screen_name) matched the username provided, and whose status column matched one of the
 values provided. These name => value pairs are used more or less directly in
 the DBIx::Class search() routine, so in most cases, you can use DBIx::Class
@@ -314,16 +314,16 @@
 The Searchargs and Resultset retrieval methods are used when more advanced
 features of the underlying L<DBIx::Class> schema are required. These methods
 provide a direct interface with the DBIx::Class schema and therefore
-require a better understanding of the DBIx::Class module.  
+require a better understanding of the DBIx::Class module.
 
 =head3 The dbix_class key
 
 Since the format of these arguments are often complex, they are not keys in
-the base authinfo hash.  Instead, both of these arguments are placed within 
-a hash attached to the store-specific 'dbix_class' key in the base $authinfo 
+the base authinfo hash.  Instead, both of these arguments are placed within
+a hash attached to the store-specific 'dbix_class' key in the base $authinfo
 hash.  When the DBIx::Class authentication store sees the 'dbix_class' key
 in the passed authinfo hash, all the other information in the authinfo hash
-is ignored and only the values within the 'dbix_class' hash are used as 
+is ignored and only the values within the 'dbix_class' hash are used as
 though they were passed directly within the authinfo hash.  In other words, if
 'dbix_class' is present, it replaces the authinfo hash for processing purposes.
 
@@ -332,7 +332,7 @@
 modification of the authinfo hash, or to avoid overlap between credential and
 store key names. It's a good idea to avoid using it in this way unless you are
 sure you have an overlap/modification issue. However, the two advanced
-retrieval methods, B<searchargs> and B<resultset>, require its use, as they 
+retrieval methods, B<searchargs> and B<resultset>, require its use, as they
 are only processed as part of the 'dbix_class' hash.
 
 =over 4
@@ -345,18 +345,18 @@
 the user.  An example will probably make more sense:
 
     if ($c->authenticate(
-        { 
+        {
             password => $password,
-            'dbix_class' => 
+            'dbix_class' =>
                 {
                     searchargs => [ { -or => [ username => $username,
                                               email => $email,
-                                              clientid => $clientid ] 
+                                              clientid => $clientid ]
                                    },
-                                   { prefetch => qw/ preferences / } 
+                                   { prefetch => qw/ preferences / }
                                  ]
                 }
-        } ) ) 
+        } ) )
     {
         # do successful authentication actions here.
     }
@@ -374,13 +374,13 @@
 
     my $rs = $c->model('MyApp::User')->search({ email => $c->request->params->{'email'} });
        ... # further $rs adjustments
-       
-    if ($c->authenticate({ 
+
+    if ($c->authenticate({
                            password => $password,
                            'dbix_class' => { resultset => $rs }
                          })) {
        # do successful authentication actions here.
-    } 
+    }
 
 Be aware that the resultset method will not verify that you are passing a
 resultset that is attached to the same user_model as specified in the config.
@@ -394,13 +394,13 @@
 
 NOTE ALSO:  The user info used to save the user to the session and to retrieve
 it is the same regardless of what method of retrieval was used.  In short,
-the value in the id field (see 'id_field' config item) is used to retrieve the 
+the value in the id field (see 'id_field' config item) is used to retrieve the
 user from the database upon restoring from the session.  When the DBIx::Class storage
 module does this, it does so by doing a simple search using the id field.  In other
-words, it will not use the same arguments you used to request the user initially. 
-This is especially important to those using the advanced methods of user retrieval. 
+words, it will not use the same arguments you used to request the user initially.
+This is especially important to those using the advanced methods of user retrieval.
 If you need more complicated logic when reviving the user from the session, you will
-most likely want to subclass the L<Catalyst::Authentication::Store::DBIx::Class::User> class 
+most likely want to subclass the L<Catalyst::Authentication::Store::DBIx::Class::User> class
 and provide your own for_session and from_session routines.
 
 =back
@@ -408,10 +408,10 @@
 
 =head1 METHODS
 
-There are no publicly exported routines in the DBIx::Class authentication 
-store (or indeed in most authentication stores). However, below is a 
-description of the routines required by L<Catalyst::Plugin::Authentication> 
-for all authentication stores.  Please see the documentation for 
+There are no publicly exported routines in the DBIx::Class authentication
+store (or indeed in most authentication stores). However, below is a
+description of the routines required by L<Catalyst::Plugin::Authentication>
+for all authentication stores.  Please see the documentation for
 L<Catalyst::Plugin::Authentication::Internals> for more information.
 
 
@@ -419,7 +419,7 @@
 
 Constructs a new store object.
 
-=head2 find_user ( $authinfo, $c ) 
+=head2 find_user ( $authinfo, $c )
 
 Finds a user using the information provided in the $authinfo hashref and
 returns the user, or undef on failure. This is usually called from the
@@ -438,7 +438,7 @@
 
 =head2 user_supports
 
-Provides information about what the user object supports.  
+Provides information about what the user object supports.
 
 =head2 auto_update_user( $authinfo, $c, $res )
 




More information about the Catalyst-commits mailing list