[Catalyst-dev] user_field in Catalyst::Plugin::Authentication::Store::LDAP

[Matt S Trout]

On Thu, Jan 24, 2008 at 11:25:12AM -0600, Peter Karman wrote:
> Resending this to jog the conversation.
> 
> On 12/02/2007 01:36 PM, Adam Jacob wrote:
> > On 11/30/07, *Carl Johnstone* <catalyst at fadetoblack.me.uk
> > <mailto:catalyst at fadetoblack.me.uk>> wrote:
> > 
> >     So once a user has actually logged in, it's the uidNumber that's
> >     important
> >     to us.
> > 
> >     So reading the documentation I figured that my search filter would be
> >     "(mail=%s)" and my user_field would be "uidNumber". I then would
> >     just need
> >     to call
> > 
> >     $c->login( $c->req->param('email'), $c->req->param('password'));
> > 
> >     However it wasn't working. Tracking the problem down, and in my case
> >     this
> >     chunk of code is checking each result to see if the id passed into
> >     login
> >     matched the user_field. In my case it check that the email address
> >     matches
> >     uidNumber, so was always failing:
> > 
> >       RESULT: while (my $entry = $usersearch->pop_entry) {
> >             foreach my $field (@user_fields) {
> >                 foreach my $value ($entry->get_value($field)) {
> >                     if ($value eq $id) {
> >                         $userentry = $entry;
> >                         last RESULT;
> >                     }
> >                 }
> >             }
> >         }
> > 
> > 
> >     However the existence of that chunk of code doesn't make sense to
> >     me, you
> >     already get the chance to filter the results when doing the query on the
> >     server. All that would seem to be doing is doing the exact same thing
> >     _again_ on the client side.
> > 
> > 
> > I think the intent here is that your search results might not be unique,
> > and so you still have to check the actual user_field to see if you have
> > the right object.  In practice, it's hard to see a situation where this
> > makes much sense... if the search filter returned more than one object
> > (and we process the filter with the login credentials) then we probably
> > have a failure condition anyway.
> > 
> > Is anyone using this functionality any different?  If they aren't, I
> > would happily take a patch to fix this.
> > 
> 
> I am working on the ::Store::LDAP code atm, and can patch this if the consensus is that
> there should only ever be one entry returned from a LDAP search. That makes sense to me;
> why would I ever have a case where there are 2 identical usernames in my LDAP tree. How
> would I know which one to authenticate against?

I think I'd consider the second entry either a warning or an error depending
on taste.

Maybe it should be permitted to provide a filter sub that would be used
first in the cases where the user wants to disambiguate on the perl-side
and then have the warn/error code after that.

-- 
      Matt S Trout       Need help with your Catalyst or DBIx::Class project?
   Technical Director                    http://www.shadowcat.co.uk/catalyst/
 Shadowcat Systems Ltd.  Want a managed development or deployment platform?
http://chainsawblues.vox.com/            http://www.shadowcat.co.uk/servers/