Thread: chasing referrals

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Can Net::LDAP automatically chase referrals?  Sample code?

Thanks,
Robbie Allen

Hello!

I feel a need to chase referrals.  I am getting the idea that this is 
not default behavior for perl-ldap.  How can I make this happen for me?

Thank you!
Terry

From: "Terry Davis" <td...@bi...>
> I feel a need to chase referrals.  I am getting the idea that this is
> not default behavior for perl-ldap.  How can I make this happen for me?

You right - this is not default behaviour. The overall consensus is that it
must be up to the application, when and how to chase referrals. Especially
authentication against the referred-to server needs to done carefully.

Basically, you're on your own. One point, though: LDAPv2 doesn't handle
referrals very elegantly - the response code for a referral is
LDAP_PARTIAL_RESULTS, which is also used for - you guessed it - partial
results... LDAPv3 has much better granularity, and a specific LDAP_REFERRAL
return code.

> Terry

/Lars

That seems broken.  That whole missing idea competely breaks 
replication.  I was reading up a little bit and I see that you can 
possibly get a list of referrals from Net::ldap::message.
Is this correct?

If so, how ?  I am quite a n00b.  

Thank you!

Lars Thegler wrote:

>From: "Terry Davis" <td...@bi...>
>
>>I feel a need to chase referrals.  I am getting the idea that this is
>>not default behavior for perl-ldap.  How can I make this happen for me?
>>
>
>You right - this is not default behaviour. The overall consensus is that it
>must be up to the application, when and how to chase referrals. Especially
>authentication against the referred-to server needs to done carefully.
>
>Basically, you're on your own. One point, though: LDAPv2 doesn't handle
>referrals very elegantly - the response code for a referral is
>LDAP_PARTIAL_RESULTS, which is also used for - you guessed it - partial
>results... LDAPv3 has much better granularity, and a specific LDAP_REFERRAL
>return code.
>
>>Terry
>>
>
>/Lars
>

From: "Terry Davis" <td...@bi...>
> That seems broken.  That whole missing idea competely breaks
> replication.  I was reading up a little bit and I see that you can

I don't really see your point about replication. In my mind, replication and
referrals has very little to do with each other. Please enlighten me :-)

> possibly get a list of referrals from Net::ldap::message.
> Is this correct?

Yes. Use the ->referrals() method. "Returns a list of referrals from the
result message" as it says in the man page. You'll have to do a re-bind
based on the result, of course.

/Lars

Perhaps I am using the wrong terminology (very possible).

The whole point of having a slave is so you can replicate your data to 
multiple places for redundancy and load balancing.
If a modify hits my slave, the slave should refer that request onto my 
master ldap server.  If the client that is hitting the slave server 
cannot handle referrals properly, then you cannot perform updates with 
that slave server.  You will be forced to set your client to use the 
master all of the time for updates.  It makes it difficult to 
differentiate between updates and reads to define which host you must 
hit to perform that  operation.  This breaks the whole load balancing 
idea.  

Am I off base here?  It is late and I am hungry so I wont be surprised.  :)
I cheated and am using ldapmodify which supports chasing referrals 
natively.  But I would like to use net::ldap because it is cooler.

Lars Thegler wrote:

>From: "Terry Davis" <td...@bi...>
>
>>That seems broken.  That whole missing idea competely breaks
>>replication.  I was reading up a little bit and I see that you can
>>
>
>I don't really see your point about replication. In my mind, replication and
>referrals has very little to do with each other. Please enlighten me :-)
>
>>possibly get a list of referrals from Net::ldap::message.
>>Is this correct?
>>
>
>Yes. Use the ->referrals() method. "Returns a list of referrals from the
>result message" as it says in the man page. You'll have to do a re-bind
>based on the result, of course.
>
>/Lars
>

On Wed, Nov 28, 2001 at 08:35:08AM +0100, Lars Thegler wrote:
> From: "Terry Davis" <td...@bi...>
> > I feel a need to chase referrals.  I am getting the idea that this is
> > not default behavior for perl-ldap.  How can I make this happen for me?
> 
> You right - this is not default behaviour. The overall consensus is that it
> must be up to the application, when and how to chase referrals. Especially
> authentication against the referred-to server needs to done carefully.

Yes, you are right. But that does not mean Net::LDAP could not provide a framework
to help it happen.

Basically my thought was that the user would have to tell Net::LDAP that they want
to chase referrals by registering a sub which, given an LDAP URL, would create the
connection and do the auth.

I have not thought much beyond that, so if anyone want to bounce a few ideas, go ahead

Graham.

> Basically my thought was that the user would have to tell Net::LDAP
> that they want to chase referrals by registering a sub which, given an
> LDAP URL, would create the connection and do the auth.
>
> I have not thought much beyond that, so if anyone want to bounce a few
> ideas, go ahead

I think the ability to pass in a sub to do the bind is a good idea.

Presumably one concern is that chasing a referral attempts a bind to
another server, which involves presenting credentials, sometimes a
cleartext password.

Two thoughts are:

- a referral chase could perform an anonymous bind (fail-safe as regards
password leakage) using the same protocol version [not by default, but as
an option]

- a facility could be provided to declare a list of 'trusted' or
'equivalent' servers. Referrals to these servers should replay the
original credentials if possible (perhaps falling back to the
user-supplied sub if that fails).

Of course these could be accomplished with the 'sub' approach, but is
either of the two bullets above useful behaviour?

regards,

jb

On Wed, Nov 28, 2001 at 03:00:31PM +0000, John Berthels wrote:
> > Basically my thought was that the user would have to tell Net::LDAP
> > that they want to chase referrals by registering a sub which, given an
> > LDAP URL, would create the connection and do the auth.
> >
> > I have not thought much beyond that, so if anyone want to bounce a few
> > ideas, go ahead
> 
> I think the ability to pass in a sub to do the bind is a good idea.

Not just the bind, the connection too. This would allow the application
to do cacheing of the connections if it whished. I do not expect
Net::LDAP to cache connections from chasing referrals.

> Presumably one concern is that chasing a referral attempts a bind to
> another server, which involves presenting credentials, sometimes a
> cleartext password.

Right, but with this approach that is completely under the control of the application

> Two thoughts are:
> 
> - a referral chase could perform an anonymous bind (fail-safe as regards
> password leakage) using the same protocol version [not by default, but as
> an option]

We could have an option which would do this. It could be simply be done
by exporting a sub which does this and can be passed to Net::LDAP
to open the connection.

> - a facility could be provided to declare a list of 'trusted' or
> 'equivalent' servers. Referrals to these servers should replay the
> original credentials if possible (perhaps falling back to the
> user-supplied sub if that fails).

I do not like this idea at all. it means that Net::LDAP must remember
the credentials that a user binds with. It does not do that now, nor
di I really want it to.

Graham.

> Of course these could be accomplished with the 'sub' approach, but is
> either of the two bullets above useful behaviour?
> 
> regards,
> 
> jb
> 

> 
> On Wed, Nov 28, 2001 at 03:00:31PM +0000, John Berthels wrote:
> > > Basically my thought was that the user would have to tell Net::LDAP
> > > that they want to chase referrals by registering a sub which, given an
> > > LDAP URL, would create the connection and do the auth.
> > >
> > > I have not thought much beyond that, so if anyone want to bounce a few
> > > ideas, go ahead
> > 
> > I think the ability to pass in a sub to do the bind is a good idea.
> 
> Not just the bind, the connection too. This would allow the application
> to do cacheing of the connections if it whished. I do not expect
> Net::LDAP to cache connections from chasing referrals.
> 
> > Presumably one concern is that chasing a referral attempts a bind to
> > another server, which involves presenting credentials, sometimes a
> > cleartext password.
> 
> Right, but with this approach that is completely under the control of the application
> 

I would like to see everything stay with application/user supplied 
subroutine. This puts the application/user in control of everything.  
Odds are that any of us that chase referrals already have this 
methodology implemented.

Clif

It seems that if the user opts to have Net::LDAP remember the credentials
it is no different then if the user's program stores the credentials.

I think the facility for automatically chasing referrals should exist
withing Net::LDAP.  The user must opt to use it.  The chasing process
should also be very well defined in the docs so that a user can decide
when they may need to implement it themselves.  Simply because the code
will not cover every chasing scenario, doesn't mean it won't be useful for
many senarios.

Why should everyone have to write and test their own code for chasing
referrals when a well planned approach within Net::LDAP would sufice for
many people.  After all, it would be optional.

- Christoph

On Wed, 28 Nov 2001, Clif Harden wrote:

> > 
> > On Wed, Nov 28, 2001 at 03:00:31PM +0000, John Berthels wrote:
> > > > Basically my thought was that the user would have to tell Net::LDAP
> > > > that they want to chase referrals by registering a sub which, given an
> > > > LDAP URL, would create the connection and do the auth.
> > > >
> > > > I have not thought much beyond that, so if anyone want to bounce a few
> > > > ideas, go ahead
> > > 
> > > I think the ability to pass in a sub to do the bind is a good idea.
> > 
> > Not just the bind, the connection too. This would allow the application
> > to do cacheing of the connections if it whished. I do not expect
> > Net::LDAP to cache connections from chasing referrals.
> > 
> > > Presumably one concern is that chasing a referral attempts a bind to
> > > another server, which involves presenting credentials, sometimes a
> > > cleartext password.
> > 
> > Right, but with this approach that is completely under the control of the application
> > 
> 
> I would like to see everything stay with application/user supplied 
> subroutine. This puts the application/user in control of everything.  
> Odds are that any of us that chase referrals already have this 
> methodology implemented.
> 
> Clif

I personally like the facility to have a list of trusted hosts.

John Berthels wrote:

>>Basically my thought was that the user would have to tell Net::LDAP
>>that they want to chase referrals by registering a sub which, given an
>>LDAP URL, would create the connection and do the auth.
>>
>>I have not thought much beyond that, so if anyone want to bounce a few
>>ideas, go ahead
>>
>
>I think the ability to pass in a sub to do the bind is a good idea.
>
>
>Presumably one concern is that chasing a referral attempts a bind to
>another server, which involves presenting credentials, sometimes a
>cleartext password.
>
>
>Two thoughts are:
>
>- a referral chase could perform an anonymous bind (fail-safe as regards
>password leakage) using the same protocol version [not by default, but as
>an option]
>
>- a facility could be provided to declare a list of 'trusted' or
>'equivalent' servers. Referrals to these servers should replay the
>original credentials if possible (perhaps falling back to the
>user-supplied sub if that fails).
>
>Of course these could be accomplished with the 'sub' approach, but is
>either of the two bullets above useful behaviour?
>
>regards,
>
>jb
>

-- 
Terry Davis
Systems Administrator
BirdDog Solutions, Inc.
(402) 829-6059
www.birddog.com

On Tue, Oct 17, 2000 at 05:27:49PM -0700, Robbie Allen wrote:
> Can Net::LDAP automatically chase referrals?  Sample code?

Not yet. Currently you have to follow them yourself. You can
get them with

  $mesg = $ldap->search( ... );
  @referrals = $mesg->referrals;

Graham.

Graham Barr <gb...@po...> wrote:
> On Tue, Oct 17, 2000 at 05:27:49PM -0700, Robbie Allen wrote:
>> Can Net::LDAP automatically chase referrals?  Sample code?
> 
> Not yet. Currently you have to follow them yourself. You can
> get them with
> 
>   $mesg = $ldap->search( ... );
>   @referrals = $mesg->referrals;
> 
> Graham.

I'm not sure Net::LDAP should ever automatically follow referrals - not
knowing what authentication to use is a pretty major problem. Deciding
which one to follow if there are several for the same point is another
(equally critical in some environments) problem.

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

Cheers,

Chris

On Wed, Oct 18, 2000 at 08:37:53AM +0100, Chris Ridd wrote:
> Graham Barr <gb...@po...> wrote:
> > On Tue, Oct 17, 2000 at 05:27:49PM -0700, Robbie Allen wrote:
> >> Can Net::LDAP automatically chase referrals?  Sample code?
> > 
> > Not yet. Currently you have to follow them yourself. You can
> > get them with
> > 
> >   $mesg = $ldap->search( ... );
> >   @referrals = $mesg->referrals;
> > 
> > Graham.
> 
> I'm not sure Net::LDAP should ever automatically follow referrals - not
> knowing what authentication to use is a pretty major problem. Deciding
> which one to follow if there are several for the same point is another
> (equally critical in some environments) problem.
> 
> Referral following is something that needs to be addressed in the
> application (eg GUI) rather than down at the API level. IMHO of course.

While I agree with your points, the API could allow the application to
register callbacks for these situations. For example to connect there
could be a callback which is passed the referral, this would return a
valid ldap object

Graham.

> 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

On Wed, Oct 18, 2000 at 10:12:04AM +0100, John Berthels wrote:
> 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?

The problem with this is that you either create many sub-classes, which means any
user needs to create a sub-class of those if they want to use many, or
you end up with one big subclass, which will be bloated.

My suggestion I posted a few days back was something like

  use Net::LDAP::Extn qw(my_extension);

which looked for the named extension and loaded it. this would make the
method my_extension avaliable on all Net::LDAP objects.

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

Not sure, but maybe.

Graham.

> 
> Graham Barr <gb...@po...> wrote:
> > On Tue, Oct 17, 2000 at 05:27:49PM -0700, Robbie Allen wrote:
> >> Can Net::LDAP automatically chase referrals?  Sample code?
> > 
> > Not yet. Currently you have to follow them yourself. You can
> > get them with
> > 
> >   $mesg = $ldap->search( ... );
> >   @referrals = $mesg->referrals;
> > 
> > Graham.
> 
> I'm not sure Net::LDAP should ever automatically follow referrals - not
> knowing what authentication to use is a pretty major problem. Deciding
> which one to follow if there are several for the same point is another
> (equally critical in some environments) problem.
> 
> Referral following is something that needs to be addressed in the
> application (eg GUI) rather than down at the API level. IMHO of course.
> 
> Cheers,
> 
> Chris
> 

I agree with Chris on this issue.  Chasing referrals should be 
left up to the application that initiated the ldap action.

Regards,

Clif Harden           INTERNET:  c-h...@ti...

> > Referral following is something that needs to be addressed in the
> > application (eg GUI) rather than down at the API level. IMHO of course.
> 
> I agree with Chris on this issue.  Chasing referrals should be 
> left up to the application that initiated the ldap action.

I'm prepared to be convinced. Why do you (and Chris) think this? (Given
that a callback allows the 'which referral to follow' and the 'how do I
bind to this server' problems to be addressed).

My point of view is that all/many/most applications which implement
referral-chasing functionality will (apart from the decisions we need to
pull out into the callbacks above) do so with very similar code.

Pushing that similar code into the API makes the app writer's life easier
and leads to one code-base to debug. The best reason I see not to do this
would be bloat. If we can get a good extension mechanism going I see no
reason (excepting someone's time to write it) not to do it.

regards,

jb

> 
> 
> > > Referral following is something that needs to be addressed in the
> > > application (eg GUI) rather than down at the API level. IMHO of course.
> > 
> > I agree with Chris on this issue.  Chasing referrals should be 
> > left up to the application that initiated the ldap action.
> 
> I'm prepared to be convinced. Why do you (and Chris) think this? (Given
> that a callback allows the 'which referral to follow' and the 'how do I
> bind to this server' problems to be addressed).

From everything I have read it is the industry standard to let the
application or client make the decision on what to do with the 
referral.  Is the right or wrong way to view the situation, I do not 
know. 

If you are talking about a referral callback function that the 
user/application defines, and controls when it is taken, then 
possibly you could say that this proposal meets this standard.  

> 
> My point of view is that all/many/most applications which implement
> referral-chasing functionality will (apart from the decisions we need to
> pull out into the callbacks above) do so with very similar code.
> 

It is quite possible that applications will implement 
referral-chasing functionality in similar code, in this case put 
the code in a "package/module" external to the perl-ldap module.  
Then the user can decide to use or not to use the code.

> Pushing that similar code into the API makes the app writer's life easier
> and leads to one code-base to debug. The best reason I see not to do this
> would be bloat. If we can get a good extension mechanism going I see no
> reason (excepting someone's time to write it) not to do it.
> 

The speed of the perl-ldap module has become an issue with some people.
I remmeber several discussions on this list about it.  The more we bloat
the code the worse this problem is going to become.  

If you can do this with a autoloading function that is compiled only
when first called, then bloat is less a problem.

> regards,
> 
> jb
> 
> 

John I am not saying that your idea is bad, I am just saying I do not
think it should be in the perl-ldap module.  

It might be a good starting point for a perl-ldap utilities module.

Regards,

Clif Harden           INTERNET:  c-h...@ti...

On Wed, Oct 18, 2000 at 11:17:42AM -0500, Clif Harden wrote:
> The speed of the perl-ldap module has become an issue with some people.
> I remmeber several discussions on this list about it.  The more we bloat
> the code the worse this problem is going to become.  

This is true.

> If you can do this with a autoloading function that is compiled only
> when first called, then bloat is less a problem.

But it may not take much. If we can devise a message chaining scheme, then
that may be all that is needed.

A callback on a search can already detect if it has referrals, if it does
then it dould need to create the connection and chain in the response.

Right now the `naughty' way is to

sub callback {
  my ($mesg, $entry) = @_;

  if (my @refs = $mesg->referrals) {
    $ldap = ... connect bind ...
    $mesg = ... do the search ...
    push @{$mesg->{entries}}, $mesg->entries;
  }
}

Graham.

Clif Harden wrote:

> If you are talking about a referral callback function that the
> user/application defines, and controls when it is taken, then possibly
> you could say that this proposal meets this standard.

OK. Thats fair enough.

> It is quite possible that applications will implement referral-chasing
> functionality in similar code, in this case put the code in a
> "package/module" external to the perl-ldap module.  Then the user can
> decide to use or not to use the code.

Yes. I think this is the nub of the discussion. No one seems opposed to
having code around which could make life easier, but not everyone agrees
where that code should live.

> The speed of the perl-ldap module has become an issue with some
> people. I remmeber several discussions on this list about it.  The
> more we bloat the code the worse this problem is going to become.
> 
> If you can do this with a autoloading function that is compiled only
> when first called, then bloat is less a problem.

It seems to me that there are two reasons why people might not want this
(and other) code in Net::LDAP (please feel free to chip in with your own
reaons if I've not caught them here):

1 - bloat (generally considered bad, although one person's bloat is
another person's feature, obviously)

2 - cleanliness of abstraction (is Net::LDAP an interface to the LDAP
protocol or an API intended to be of use to LDAP using applications?)

We can try to attack (1) with autoloading and extensions etc. (2) seems
more problematic.

I'm pretty much on the fence. All I'd like a framework (within or without
Net::LDAP) where I can find more cool things (LDAP referral following,
complex attribute value handling, multilingual attribute handling, Tk
widgets for syntaxes, whatever) and perhaps help create them.

You could argue that that framework should be CPAN rather than Net::LDAP
and you could well be right.

Where does everybody else stand?

jb

>I'm pretty much on the fence. All I'd like a framework (within or without
>Net::LDAP) where I can find more cool things (LDAP referral following,
>complex attribute value handling, multilingual attribute handling, Tk
>widgets for syntaxes, whatever) and perhaps help create them.
>
>You could argue that that framework should be CPAN rather than Net::LDAP
>and you could well be right.
>
>Where does everybody else stand?

I tend to be on the more liberal side most of the time.  I would like to
see a Net::LDAP that has as many advanced features available, and as many
"cool things" as people are willing to write into it, the more the
merrier...so long as they are not "code for codes sake".   If people are
going to use/write them, include them I say.  

That said however, there obviously needs to be methods in place for people
to "try out" new "bloat", before it's included into the standard product
and regretted later for one reason or another.

Why not have a Net::LDAP-dev or something that gets everything that people
are willing to throw at it, and include only those that are
"tried-and-true" into the real release? That should please both sides of
the fence...  I mean, look at the name of this list, it's a DEVELOPERS
list, be game, try everything, have a shot, live once, carpe-deim,
seize-the-day....

<at about this point in time you find the author standing on his desk
peering off into the distance, wondering whether his desk set will fly....>

--------------------------------------------------------------------
David Bussenschutt          Email: D.B...@ma...
Senior Computing Support Officer & Systems Administrator/Programmer
Location: Griffith University. Information Technology Services
          Brisbane Qld. Aust.  (TEN bldg. rm 1.33) Ph: (07)38757079
--------------------------------------------------------------------

Instead of a seperate callback, perhaps the entry object in the current
callback could be a referral:

my callback {
   my ($msg,$obj) = @_;

   if (ref ($obj) eq 'Net::LDAP::Referral')
   {
       ....
   } 
   elsif (ref ($obj) eq 'Net::LDAP::Entry')
   {
      ...
   }
}

IMHO that's a better way to handle it. The application programmer has the
choice (and responsiblility) of what to handle, it doesn't bloat
the current API and everyone should be happy :).

Then you could populate the @entries and @referrals structures after
checking for the callback.

The optimal solution, is the way the Netscape Directory SDK for Java does
it. Any referrals found get thrown as an exception, thus you can choose to
deal with the exception or ignore it. But since we don't have real
exceptions in Perl, that's not possible :).

 Mark

On Wed, 18 Oct 2000, John Berthels wrote:

> 
> > > Referral following is something that needs to be addressed in the
> > > application (eg GUI) rather than down at the API level. IMHO of course.
> > 
> > I agree with Chris on this issue.  Chasing referrals should be 
> > left up to the application that initiated the ldap action.
> 
> I'm prepared to be convinced. Why do you (and Chris) think this? (Given
> that a callback allows the 'which referral to follow' and the 'how do I
> bind to this server' problems to be addressed).
> 
> My point of view is that all/many/most applications which implement
> referral-chasing functionality will (apart from the decisions we need to
> pull out into the callbacks above) do so with very similar code.
> 
> Pushing that similar code into the API makes the app writer's life easier
> and leads to one code-base to debug. The best reason I see not to do this
> would be bloat. If we can get a good extension mechanism going I see no
> reason (excepting someone's time to write it) not to do it.
> 
> regards,
> 
> jb
> 
> 

At 08:37 AM 10/18/00 +0100, Chris Ridd wrote:
>Graham Barr <gb...@po...> wrote:
>> On Tue, Oct 17, 2000 at 05:27:49PM -0700, Robbie Allen wrote:
>>> Can Net::LDAP automatically chase referrals?  Sample code?
>> 
>> Not yet. Currently you have to follow them yourself. You can
>> get them with
>> 
>>   $mesg = $ldap->search( ... );
>>   @referrals = $mesg->referrals;
>> 
>> Graham.
>
>I'm not sure Net::LDAP should ever automatically follow referrals - not
>knowing what authentication to use is a pretty major problem. Deciding
>which one to follow if there are several for the same point is another
>(equally critical in some environments) problem.
>
>Referral following is something that needs to be addressed in the
>application (eg GUI) rather than down at the API level. IMHO of course.

I concur that the low-level API should have not chase referrals.
The abstraction at the low-level should be a "protocol" session.

This, of course, doesn't mean you cannot have a higher level API
which provides different abstractions.  For example, one could
create a "Directory" abstraction which managed multiple protocol
sessions.

Kurt

Thread: chasing referrals

perl-ldap-dev