[Catalyst] [patch] Catalyst::Authentication::Store::DBIx::Class's authenticate parameters Documentation

[Jason Kuri]

Hi Greg,

Thanks for the patch.  You're right - this is confusing behavior.

The cause of the problem is that any fields passed to authenticate
that don't match fields in the user table are ignored.  This is done
to ensure that any fields that may relate to other credentials /
stores / realms involved in authentication are not mistakenly passed
to search.   The practical upshot of this is that if your username
field is different in the db than it is on the authenticate call, it
winds up being ignored.  The behavior you see is the same as calling
$user_rs->search({})->first;

I actually have a fix in my local sources which throws a big fit if it
winds up with no fields to search with... which clears up the
confusion pretty well.

I've incorporated your 'username' change in the authenticate call to
the docs also.  Though the id_field explanation is not quite right.

I've updated the id_field documentation, hopefully to clear things
up.  I'll see about pushing a new rev up in the next few days.

The new id_field doc snippit is below.

--- snip ---
=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 it's 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
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.

--- snip ---

Does that clear things up for you?

Jay

On Sep 15, 2008, at 3:59 AM, Greg Matheson wrote:

> t0m and others on #catalyst helped me understand that the
> 'username' key-value pair I was passing to authenticate was
> resulting in the first user in the user_class table being
> authenticated, a problem that has apparently been met by others
> too. See the message at
> http://lists.scsys.co.uk/pipermail/catalyst/2008-August/019560.html.
>
> I had a different table column in id_field.
>
> I thought the POD could be made more informative about this
> problem, so prepared a patch.
>
> What it does is replace 'username' as the keyname passed to
> authenticate with 'user_id', the value of the id_field
> configuration option used in the example in the Synopsis.
>
> However, the exchange between Matt Trout and Jay Kuri following
> the above message has muddied my understanding and I haven't
> cleared this confusion by reading the source or by reading about
> DBIx::Class's search routine.
>
> So feel freee to ignore this patch if it makes what appears to be
> 'widespread' confusion worse.
>
> [drbean at localhost dic]$ diff -u Class.pm.orig Class.pm
> --- Class.pm.orig	2008-09-15 17:39:37.000000000 +0800
> +++ Class.pm	2008-09-15 17:48:30.000000000 +0800
> @@ -127,7 +127,7 @@
>         my ( $self, $c ) = @_;
>
>         $c->authenticate({
> -                          username => $c->req->params->username,
> +                          user_id => $c->req->params->username,
>                           password => $c->req->params->password,
>                           status => [ 'registered', 'loggedin',
> 'active']
>                           }))
> @@ -270,7 +270,7 @@
> is below:
>
>     if ($c->authenticate({
> -                          username => $c->req->params->{'username'},
> +                          user_id => $c->req->params->{'username'},
>                           password => $c->req->params->{'password'},
>                           status => [ 'registered', 'active',
> 'loggedin']
>                          })) {
> @@ -278,11 +278,12 @@
>         # ... authenticated user code here
>     }
>
> -The above example would attempt to retrieve a user whose username
> column
> -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
> -syntax to retrieve the user according to whatever rules you have.
> +The above example would attempt to retrieve a user whose username
> column (here,
> +'user_id') matched the username provided, and whose status column
> matched one
> +of the values provided. (The username column name may be specified
> by the
> +id_field configuration option.) 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 syntax to retrieve the user according to whatever rules
> you have.
>
> NOTE: Because the password in most cases is encrypted - it is not used
> directly but it's encryption and comparison with the value provided
> is usually
>
>
>
> _______________________________________________
> List: Catalyst at lists.scsys.co.uk
> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
> Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
> Dev site: http://dev.catalyst.perl.org/