[Catalyst] Patch for Catalyst::Authentication::Store::DBIx::Class::User

Jason Kuri jayk at ion0.com
Fri Aug 22 16:42:07 BST 2008


>> On Thursday 21 August 2008 23:12:40 David Jack Wange Olrik wrote:
>>> Wouldn't it be neat to have the username field configurable, just
>>> like 'password_field' ?
>>
>> You don't need that, read this:
>> [ ... ]
>> Basically you pass whatever hashref you need to $c->authenticate. The
>> password_field is necessary because of the possible changes done by
>> Credential::Password .
>
> I think the point is that it should be possible to rename fields on
> the
> DBIC side without eneding to change your $c->authenticate line.

I disagree.  The goal seems to be to loosely bind to the DB fields
from the auth side.  This should be handled long before the
DBIx::Class store.

The problem is that If we made 'username' configurable, we would have
to make every field configurable.  We'd need essentially a map of
'inbound fields' to 'fields to send to ->search()' because username is
only one of the possible ways to search users during authentication.

To do it properly, we'd also have to make a generic way to handle
values and translate them to what would be in the database.  Taking
the example from the POD  status => 'active'  in the auth call would
need to be translatable to a 'user_access_level' field which could
have the values of 'logged in' 'registered' or 'admin'.

There are too many more reasonable ways to accomplish this in an
application that would not be convoluted and would not bury the fact
that it is occuring at all.  Adding it at the store level would be
difficult to do well for relatively questionable gain.

Jay




More information about the Catalyst mailing list