Re: chasing referrals

[John B. <joh...@ne...>]

> I'm not sure Net::LDAP should ever automatically follow referrals -
> not knowing what authentication to use is a pretty major problem.

We could select chase/not chase with an option to the constructor.

I would suggest handling the different auth needs by permitting a callback
to be passed in. If the callback is absent then the same credentials are
re-presented. (Hmmm...this makes sense to me for usability reasons but it
feels pretty unpleasant from the security standpoint...maybe "represent
the same credentials" shouldn't be a default if we are chasing referrals).

> Deciding which one to follow if there are several for the same point
> is another (equally critical in some environments) problem.

Hmm. How about:

my $l = Net::LDAP->new( ..., referrals => &ref_callback );

sub ref_callback {
	my @ldap_urls = @_;
	...decide which order I want to contact these in
	...and how I should authenticate against them
	return \%hash_mapping_url_to_auth_info;
}

If you specify the string 'default' instead of a subroutine ref then you
get the default referral handler, which keeps the order returned by the
server and re-uses the credentials (I have qualms about this...see above).

If you don't specify the 'referrals' option to the constructor then you
get the current behaviour.

> Referral following is something that needs to be addressed in the
> application (eg GUI) rather than down at the API level. IMHO of course.

As regular readers of this list are probably aware, I favour putting code
which may be of use to many/some applications into this (or another) API
(preferably in a way which doesn't incur bloat for the common case if
possible). 

This probably brings us back to the 'what is the best way to extend
Net::LDAP' issue. Should we implement this as a subclass of Net::LDAP to
avoid bloating the core API?

Could/should this same mechanism be used to chase continuation references?


jb