开发者

How do I use composite key user ids with Catalyst::Plugin:: Authentication::DBI?

开发者 https://www.devze.com 2022-12-22 05:36 出处:网络
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)? Doe开发者_开发问答s it support this functionality? I\'

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)? Doe开发者_开发问答s 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.


  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.


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

0

精彩评论

暂无评论...
验证码 换一张
取 消

关注公众号