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


_______________________________________________
List: Catalyst@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/

Reply via email to