dbix-class at trout
Jan 25, 2008, 12:05 AM
Post #2 of 5
(485 views)
Permalink
|
|
Re: user_field in Catalyst::Plugin::Authentication::Store::LDAP
[In reply to]
|
|
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/
_______________________________________________
Catalyst-dev mailing list
Catalyst-dev[at]lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev
|
