I don't think you even need to go that far..
The DBIx::Class::User module will delegate any unknown methods onto
your user row..
So you should just be able to add your check_password method onto the
row object, without having a custom user_class..
Then you get the initial advantage I was promoting (i.e. your database
model is internally consistent, and you can use check_password outside
of a Catalyst context if you want to), and you have less code...
yes, u are absolutly right. tested it like this and it worked.
__PACKAGE__->add_columns(
'user_password' => {
encode_check_method => __PACKAGE__->check_password,
...
sub check_password {
my ($self, $pw);
...
}
but ... I decided to go for the new extended class because I still need
progressive Auth, means, some users are only in the DB (including their
password) and some are only in the LDAP-Dir.
So, if I go for the example above a normal PasswordCheck against the DB
wouldn't be possible anymore, right?
_______________________________________________
List: [email protected]
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/[email protected]/
Dev site: http://dev.catalyst.perl.org/
