views:

73

answers:

2

What is the most effective to way to make Catalyst::Plugin::Authentication work if the user uesrid is qualified by a domain (i.e. composite key)? Does it support this functionality? I'm looking specifically at using Catalyst::Plugin::Authentication::DBI but I'm not opposed to forking, patching, recreating it if it doesn't have the current functionality.

I need to login to a certain domain name with a certain password. It seems as if /all/ the C:P:A modules depend on a simple UserID / Password combination. Other examples, and hints are welcome.

+7  A: 
  1. Catalyst::Authentication::Store::DBIx::Class supports finding a user on any sort of key you like, as all of the auth info you provide (with the exception of the designated password_field) is turned into a DB query, you can do $c->authenticate({ last_name => "Fred", favorite_color => "Blue" }) if you want.

  2. Pretty much anything you can imagine is possible if you write a Realm or a Store, and there's no reason they have to be complicated -- just classes that implement one or two methods and inherit the rest. Which one you would have to use depends on the details of what your app is doing -- overriding find_user in a Realm would be the easier case; writing a new Store would be the slightly trickier one.

hobbs
A: 

The real answer is Catalyst::Plugin::Authentication requires from_session and for_user to handle only serialized keys: for_user returning the serialized key, from_session returning the user. This creates an issue because C:P:A:DBI does not currently permit multi-key users in its role implementation or in its from_session and for_user implementation. Oddly, it does permit complex key-value conditionals in user-retrieval in find_user. Currently, the draw back is a bad assumption all users are identified with a uid/guid/pkid, etc..

In order to have a user identified with a composite key the query-conditional would have to be attached to the store, or cached in the for_user serialized key. Both, of these are doable with a patch.

Oddly enough I had this same confusion last time I created an LDAP store 3 years ago.

I'll keep this question open until I patch it, fork it, or someone gives useful applicable advice to Catalyst::Plugin:: Authentication::Store::DBI. I have rewritten this module and it is available at http://github.com/EvanCarroll/Catalyst-Authentication-Store-DBI

Evan Carroll
There's no such assumption in Auth, there's no such module as Catalyst::Plugin::Authentication::DBI, and if you're talking about Catalyst::Authentication::Store::DBI the answer should be obvious. `for_session` and `from_session` merely have to be inverses.
hobbs
The assumption is in Store::DBI pertaining to users being unique on a single column and roles being retrieved with that single column.. Good catch on the module name typo.
Evan Carroll