On 28 Jan 2011, at 16:34, piccard wrote:
So put that logic in your domain model (i.e. DB row class), where
it belongs?
sorry, I'm not sure what u mean (new to Catalyst and DBIx).
I need progressive authentication.
No, you don't.
First it should check against the db and then against the
So put that logic in your domain model (i.e. DB row class), where it
belongs?
sorry, I'm not sure what u mean (new to Catalyst and DBIx).
I need progressive authentication. First it should check against the db
and then against the LDAP-dir, but using the roles from the db.
If I'm going to
You set it in the config, you implement a check_password method in
your user object (which goes and checks the password from LDAP),
you're done.
For anybody who is working on the same problem, this solution worked 4 me:
+ set the extended classin the config via the store_user_class-key
On 26 Jan 2011, at 13:48, piccard wrote:
You set it in the config, you implement a check_password method in
your user object (which goes and checks the password from LDAP),
you're done.
For anybody who is working on the same problem, this solution worked
4 me:
+ set the extended
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
On 26 Jan 2011, at 16:27, piccard wrote:
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
Hi,
Is there a possibilty to map the keys, so they also work for a
LDAP-authentication?
Yes, there is. You'll need to patch the code, but the patch would be
very welcome upstream.
Add an authinfo_remap key to the config, and the code...
if ( my $map =
On 25 Jan 2011, at 10:01, piccard wrote:
In view of that, I've got one more question. What I would really
need, is a password authentification against LDAP and if successful,
get the user and his roles from the database. So, is it possible to
split up this process and still use methods like
Am 25.01.2011 11:16, schrieb Tomas Doran:
On 25 Jan 2011, at 10:01, piccard wrote:
In view of that, I've got one more question. What I would really
need, is a password authentification against LDAP and if successful,
get the user and his roles from the database. So, is it possible to
split up
Hello,
like in the def. guide 2 catalyst described I've tested a progressive
authentication via DB and LDAP, which worked just fine :-D
But now I have to use an already existing DB, which has different
column-names. As long as I authenticate via a DB everything works,
because I can pass the
10 matches
Mail list logo
