perl-ldap-dev

Re: Secureway LDAP and binary data

[Mik F. <mi...@sp...>]

Never mind.  I figured it out.  The "version" option goes into the *new*
method, not the bind.

Excuse me while I pound my head against the RTFM.

Sorry to have bothered you all,
Mik

-- 
Mik Firestone mi...@sp...
When I become an Evil Overlord:
My troops will receive special training so that they may shoot the tires of a
moving vehicle.

Re: search filter with 'strange' characters?

[Chris R. <chr...@me...>]

Karel Bijl <Kar...@cm...> wrote:
>=20
> Hi,
>=20
> I've installed perl-ldap and it works great! I'm using it to interface
> with the ms-exchange global adress list.
>=20
> But I do have I question that I cannot find an answer for on any website
> (so far)
> I have a search filter that searches on "sn=3DDunn=E9"=20
>=20
> This guy's name has an =E9 in it... When I search for this I do not get a
> result.=20
> However if I search on a different field of this guy and look at what the
> sn field is, it states "Dunn=C3=A9"
>=20
> And when I use the regular ms outlook global adress list and look up this
> guy it returns "Dunn=E9"
>=20
> So my guess is that there are some charachter conversions somewhere? But
> sofar I've been unable to find anything that could help.

Your guess is correct.

Different versions of LDAP used different character sets. If you are using
LDAP v3 (you might not -- you should check), then all strings are Unicode
and encoded using UTF-8.

There are different ways of encoding some characters in Unicode, for
instance e-acute can either be encoded as U+00E9 (lower case e acute), or
U+0301 (non-spacing acute accent) followed by U+0065 (lower case e).

It is possible that your client can only understand one way of encoding e
acute, whereas your server understands both. So the server is interpreting
your search correctly and returning the right entry, but your client's
broken.

There are two solutions:

1) fix the clients. Tricky if one of them comes from MS or Netscape.

2) modify the entries so that they contain the encodings that the clients
understand.

A trip to www.unicode.org will provide you with nice PDF files containing
pictures of all the Unicode characters, in case you decide on option 2.

Cheers,

Chris

RE: search filter with 'strange' characters?

[Karel B. <Kar...@cm...>]

After searching for a couple of hours, looking into ldif, asn1 and such =
I
completely forgot that in stead of not getting a result, I get a =
protocol
error!

No doubt that this has something to do with the binary meaning of the =
=E9 ....
but then still, what would be necessary to convert this character into
something else? I've got a feeling that I need to use Net::LDAP::LDIF
somewhere .... but it's unclear to me how I should do that..

regards,
Karel

-----Original Message-----
From: Karel Bijl [mailto:Kar...@cm...]
Sent: woensdag 5 december 2001 17:45
To: 'per...@li...'
Subject: search filter with 'strange' characters?



Hi,

I've installed perl-ldap and it works great! I'm using it to interface =
with
the ms-exchange global adress list.

But I do have I question that I cannot find an answer for on any =
website (so
far)
I have a search filter that searches on "sn=3DDunn=E9"=20

This guy's name has an =E9 in it... When I search for this I do not get =
a
result.=20
However if I search on a different field of this guy and look at what =
the sn
field is, it states "Dunn=C3=A9"

And when I use the regular ms outlook global adress list and look up =
this
guy it returns "Dunn=E9"

So my guess is that there are some charachter conversions somewhere? =
But
sofar I've been unable to find anything that could help.


Do any of you have experience on this?

Thnx,
Karel Bijl

search filter with 'strange' characters?

[Karel B. <Kar...@cm...>]

Hi,

I've installed perl-ldap and it works great! I'm using it to interface =
with
the ms-exchange global adress list.

But I do have I question that I cannot find an answer for on any =
website (so
far)
I have a search filter that searches on "sn=3DDunn=E9"=20

This guy's name has an =E9 in it... When I search for this I do not get =
a
result.=20
However if I search on a different field of this guy and look at what =
the sn
field is, it states "Dunn=C3=A9"

And when I use the regular ms outlook global adress list and look up =
this
guy it returns "Dunn=E9"

So my guess is that there are some charachter conversions somewhere? =
But
sofar I've been unable to find anything that could help.


Do any of you have experience on this?

Thnx,
Karel Bijl

Re: [Fwd] Question on LDAP for passwords.

[Steven L. <sle...@kn...>]

>> Aside from ssl/ssh, is there any cute trick built into
>> LDAP for checking passwords without sending them in the
>> clear? Playing with it, I seem to end up either sending
>> in the password with the user query or getting it back
>> as clear text in the LDAP reply.
>
> No, that is how LDAP simple authentication works.
>
> LDAP has other authentication mechanisms that can avoid this, namely SASL.
> Perl-ldap supports the CRAM-MD5 and EXTERNAL mechanisms.

Last desparate grasp at a straw: Has anyone ever grafted
LDAP underneath digest security? Point would be to store
the "password" entries in LDAP and convert the result into
digest challanges.

thanx.

--
Steven Lembark                     500 W. Madison, Suite 3100
Knightsbridge Solutins                      Chicago, IL 60661
"Performance That Empowers"           +1 800 762 1582  x-5350

Re: [Fwd] Question on LDAP for passwords.

[Chris R. <chr...@me...>]

Graham Barr <gb...@po...> wrote:
> ----- Forwarded message from Steven Lembark <sle...@kn...>
> -----
> 
> Date: Sun, 02 Dec 2001 09:58:15 -0600
> To: gb...@po...
> From: Steven Lembark <sle...@kn...>
> Subject: Question on LDAP for passwords.
> X-Mailer: Mulberry/2.1.1 (Linux/x86)
> 
> 
> Aside from ssl/ssh, is there any cute trick built into
> LDAP for checking passwords without sending them in the
> clear? Playing with it, I seem to end up either sending
> in the password with the user query or getting it back
> as clear text in the LDAP reply.
> 
> thanx.

No, that is how LDAP simple authentication works.

LDAP has other authentication mechanisms that can avoid this, namely SASL.
Perl-ldap supports the CRAM-MD5 and EXTERNAL mechanisms.

Cheers,

Chris

[Fwd] Question on LDAP for passwords.

[Graham B. <gb...@po...>]

----- Forwarded message from Steven Lembark <sle...@kn...> -----

Date: Sun, 02 Dec 2001 09:58:15 -0600
To: gb...@po...
From: Steven Lembark <sle...@kn...>
Subject: Question on LDAP for passwords.
X-Mailer: Mulberry/2.1.1 (Linux/x86)


Aside from ssl/ssh, is there any cute trick built into
LDAP for checking passwords without sending them in the
clear? Playing with it, I seem to end up either sending
in the password with the user query or getting it back
as clear text in the LDAP reply.

thanx.

--
Steven Lembark                     500 W. Madison, Suite 3100
Knightsbridge Solutins                      Chicago, IL 60661
"Performance That Empowers"           +1 800 762 1582  x-5350

----- End forwarded message -----

Re: Problem query without filter

[Jim H. <ha...@us...>]

For your main problem, a filter that will always find everything is
  objectClass=*

I haven't used the version options.


On Tue, 4 Dec 2001, Adrien Demarez wrote:

> Hello,
> (sorry for my poor English, I'm french !)
>
> First of all, I'd like to thank you for this cool and simple module (which doesn't need to get any other SDK installed).
> But... I've got a little problem (notice I'm not an experienced LDAP user, and I'm running openldap 2.0.18, perl 5.601, perl-ldap 0.25) :
>
> 1) With a "normal" LDAP request (ldapsearch -x, for example) without filter, I get _every_ record under the base object (since the query is not filtered).
>
> But with perl-ldap (take for example the code below), I can't get anything if I don't specify a filter in the query, or if I specify "", or "*", or anything else (I get "Bad filter at ./LDAPtest2.pl"). That means I gan't get the whole tree in a simple request...
> $ldap = Net::LDAP->new("adrien.mandrakesoft.com", onerror=>"die", version=>3, timeout=>5) or die "$@";
> my $result = $ldap->search(base=>"dc=example,dc=com", scope=>"one", attrs=>['*']);    #No more results (same filter error) with filter=>"", filter=>"*", filter=>"dn=*", filter=>"dn", etc...
> foreach $entr ($result->entries) {print "dn: ", $entr->dn, "\n";}
>
> Can you help me ?
>
> 2) Another (lillte) thing with the version :
> a 'print "version LDAP : ",$ldap->version,"\n";' simply return the string passed in the "version=>" argument. That means if I do
>
> $ldap = Net::LDAP->new("adrien.mandrakesoft.com", onerror=>"die", version=>"stupid_string", timeout=>5) or die "$@";
> print "version LDAP : ",$ldap->version,"\n"; #to verify the LDAP protocol used
>
> I get "version LDAP : stupid_string" and everything continues whereas the script should die with an error like "unrecognized protocol".
>
> How can I then check the _real_ protocol used ?
>
> --
> Adrien Demarez
>

Problem query without filter

[Adrien D. <adr...@fr...>]

Hello,
(sorry for my poor English, I'm french !)

First of all, I'd like to thank you for this cool and simple module (which doesn't need to get any other SDK installed).
But... I've got a little problem (notice I'm not an experienced LDAP user, and I'm running openldap 2.0.18, perl 5.601, perl-ldap 0.25) :

1) With a "normal" LDAP request (ldapsearch -x, for example) without filter, I get _every_ record under the base object (since the query is not filtered).

But with perl-ldap (take for example the code below), I can't get anything if I don't specify a filter in the query, or if I specify "", or "*", or anything else (I get "Bad filter at ./LDAPtest2.pl"). That means I gan't get the whole tree in a simple request...
$ldap = Net::LDAP->new("adrien.mandrakesoft.com", onerror=>"die", version=>3, timeout=>5) or die "$@";
my $result = $ldap->search(base=>"dc=example,dc=com", scope=>"one", attrs=>['*']);    #No more results (same filter error) with filter=>"", filter=>"*", filter=>"dn=*", filter=>"dn", etc...
foreach $entr ($result->entries) {print "dn: ", $entr->dn, "\n";}

Can you help me ?

2) Another (lillte) thing with the version :
a 'print "version LDAP : ",$ldap->version,"\n";' simply return the string passed in the "version=>" argument. That means if I do

$ldap = Net::LDAP->new("adrien.mandrakesoft.com", onerror=>"die", version=>"stupid_string", timeout=>5) or die "$@";
print "version LDAP : ",$ldap->version,"\n"; #to verify the LDAP protocol used

I get "version LDAP : stupid_string" and everything continues whereas the script should die with an error like "unrecognized protocol".

How can I then check the _real_ protocol used ?

--
Adrien Demarez

Re: Secureway LDAP and binary data

[Clif H. <cl...@di...>]

Try turning on the Net::LDAP debug option and send the list the 
output.  The debug messages may show the problem.

Clif




> 
> This is actually two questions, but I was trying for a somewhat descriptive
> subject line.  I have tried to browse the archives, but sourceforge seems to
> be having some problems this evening.  I have also checked the FAQ and saw
> nothing that seemed appropriate.  If I have missed something, please let me
> know ( preferably with a URL ) and I will happily go RTFM.
> 
> My first question is in regards to IBM's Secureway Directory server version
> 3.2.1 and Net::LDAP.  I am trying to develop some code that is copying data
> from one LDAP server into another - don't ask why, just trust me when I say
> there are good reasons.  Everytime I tried to add or modify an existing
> object, I was received an "Insufficient authorization" error, even though I
> was binding correctly and the bind dn had sufficient auth to do such things.
> I was also able to add the objects via the command line.  The same code would
> also allow me to delete objects with great glee.  After giving up all hope, I
> had the insight to try running the same code against netscape's ldap server
> and it worked perfectly.  Are there known issues with respect to IBM's ldap
> server?  If this is a new problem, where do I start debugging?  I tried
> tracing through the code but quickly got lost.
> 
> This information being copied is binary data, and this seems to give
> Convert::ASN1::_encode a few problems in _enc_string.  It seems, in this case,
> $_[3] is undef.  Again, I tried tracing the code but quickly got lost.  Is
> this a known problem?  Is it going to cause me any grief - I have inspected
> the data and it looks like everything worked.  Again, if this is a new
> problem, I am happy to provide some test data and code.
> 
> Thanks for any help,
>   Mik 
> -- 
> Mik Firestone mi...@sp...
> When I become an Evil Overlord:
> Any and all magic and/or technology that can miraculously resurrect a
> secondary character who has given up his/her life through self sacrifice will
> be outlawed and destroyed.
> 
> 
> 

Secureway LDAP and binary data

[Mik F. <mi...@sp...>]

This is actually two questions, but I was trying for a somewhat descriptive
subject line.  I have tried to browse the archives, but sourceforge seems to
be having some problems this evening.  I have also checked the FAQ and saw
nothing that seemed appropriate.  If I have missed something, please let me
know ( preferably with a URL ) and I will happily go RTFM.

My first question is in regards to IBM's Secureway Directory server version
3.2.1 and Net::LDAP.  I am trying to develop some code that is copying data
from one LDAP server into another - don't ask why, just trust me when I say
there are good reasons.  Everytime I tried to add or modify an existing
object, I was received an "Insufficient authorization" error, even though I
was binding correctly and the bind dn had sufficient auth to do such things.
I was also able to add the objects via the command line.  The same code would
also allow me to delete objects with great glee.  After giving up all hope, I
had the insight to try running the same code against netscape's ldap server
and it worked perfectly.  Are there known issues with respect to IBM's ldap
server?  If this is a new problem, where do I start debugging?  I tried
tracing through the code but quickly got lost.

This information being copied is binary data, and this seems to give
Convert::ASN1::_encode a few problems in _enc_string.  It seems, in this case,
$_[3] is undef.  Again, I tried tracing the code but quickly got lost.  Is
this a known problem?  Is it going to cause me any grief - I have inspected
the data and it looks like everything worked.  Again, if this is a new
problem, I am happy to provide some test data and code.

Thanks for any help,
  Mik 
-- 
Mik Firestone mi...@sp...
When I become an Evil Overlord:
Any and all magic and/or technology that can miraculously resurrect a
secondary character who has given up his/her life through self sacrifice will
be outlawed and destroyed.

Re: way to try multiple servers?

[Eric P. <li...@gl...>]

> I look at the documentation for Net::LDAP::new and see that there
> is only room for one "HOST" argument.  Does this mean that there
> is no way to list several hosts to try in a failover arrangement?
> Or is there, perhaps, a way to pass Net::LDAP an already opened
> IO::Socket?

Well, I don't know about Net::LDAP::new handling failover, but I do it
myself by using a fairly short timeout:

  unless ( $ldaps =
Net::LDAPS->new($ldapserverone,port=>636,timeout=>5) ) {
    $ldaps = Net::LDAPS->new($ldapservertwo,port=>636,timeout=>20)
        || return "Can't connect to $ldapserverone or $ldapservertwo
via LDAPS: $@";
  }

This works well for me.....

Eric Parusel

way to try multiple servers?

[Chris F. <cf...@vi...>]

I look at the documentation for Net::LDAP::new and see that there
is only room for one "HOST" argument.  Does this mean that there
is no way to list several hosts to try in a failover arrangement?
Or is there, perhaps, a way to pass Net::LDAP an already opened
IO::Socket?

thanks
--
    Chris Fedde

Re: chasing referrals

[Christoph N. <en...@ap...>]

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

Re: Searching for a specific DN

[Jim H. <ha...@us...>]

my $ldap = Net::LDAP->new($host) or die "$@";
my $mesg = $ldap->search (
                               base   => "$dn",
                               scope => 'base',
                               filter => "(objectClass=Top)"
                           );
print Net::LDAP::Util::ldap_error_text($mesg->code),"\n" if $mesg->code;
foreach my $entry ($mesg->all_entries) {
  $entry->dump;
}

On Wed, 28 Nov 2001, Joseph Kezar wrote:

>   I am trying to find some sort of function to search for a particular
> DN and return a Net::LDAP::Entry.
>
> Say I know dn='cn=Joseph Kezar + uid=jkezar,ou=People,o=Vermont
> Department of Corrections,c=US'
>
> I want to be able to search for this specific record and return an Entry
> object.
> How can I do this?
>
>
> --
> Joseph Kezar
>

Searching for a specific DN

[Joseph K. <jk...@do...>]

  I am trying to find some sort of function to search for a particular
DN and return a Net::LDAP::Entry.  

Say I know dn='cn=Joseph Kezar + uid=jkezar,ou=People,o=Vermont
Department of Corrections,c=US'

I want to be able to search for this specific record and return an Entry
object.
How can I do this?


-- 
Joseph Kezar

Re: chasing referrals

[Terry D. <td...@bi...>]

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

[Fwd] Searching for specific DN

[Graham B. <gb...@po...>]

----- Forwarded message from Joseph Kezar <jk...@do...> -----

Date: Wed, 28 Nov 2001 11:49:43 -0500
To: gb...@po...
From: Joseph Kezar <jk...@do...>
Subject: Searching for specific DN
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-6smp i686)

Graham,
  I am trying to find some sort of function to search for a particular
DN and return a Net::LDAP::Entry.  

Say I know dn='cn=Joseph Kezar + uid=jkezar,ou=People,o=Vermont
Department of Corrections,c=US'

I want to be able to search for this specific record and return an Entry
object.
How can I do this?


-- 
Joseph Kezar

----- End forwarded message -----

Re: chasing referrals

[Clif H. <cl...@di...>]

> 
> 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

Re: chasing referrals

[Graham B. <gb...@po...>]

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
> 

Re: chasing referrals

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

> 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

Re: chasing referrals

[Graham B. <gb...@po...>]

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.

Re: server-less operation

[Graham B. <gb...@po...>]

On Tue, Nov 27, 2001 at 07:31:21PM +0000, John Berthels wrote:
> > > This sounds like an excellent idea. But I think it should be a sub-class
> > > of Net::LDAP.
> > >
> > > In fact, if it was a package that understood the data structures
> > > passed to Convert::ASN1. Then it could have many uses.
> > >
> > > Your subclass you mention could just call it instead of encoding
> > > with Convert::ASN1. But we could also write a simple server that
> > > could be used for testing within the distribution.
> 
> OK. I was trying to avoid ASN.1 entirely. An outline of what I intended is
> attached. (Only enough implemented to demonstrate the concept I had in
> mind - the search implementation currently matches everything in the
> LDIF).

I was not suggesting that you actually use ASN.1, but the data structures
that get passed to the Convert::ASN1 module.

Then there is little work todo to create a subclass of Net::LDAP as you only
have to override the send/recv instead of having to reimplement everything

> The idea is that (whilst testing away from a server) you can instantiate a
> Net::LDAPL (poor name I think) instead of a Net::LDAP and still test your
> app.

Sure.

Graham.

> Anyone sufficiently interested in this for me to finish it?
> 
> regards,
> 
> jb

Re: referrals

[Terry D. <td...@bi...>]

agreed.  it can be dangerous with auth stuff flying accross and should 
not be default behavior but that is why you said "option".  :)

John Berthels wrote:

>For what its worth, I think that there are many environments where chasing
>referrals automatically is useful. IMHO an option to do so would be a
>useful enhancement to the module.
>
>jb
>

referrals

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

For what its worth, I think that there are many environments where chasing
referrals automatically is useful. IMHO an option to do so would be a
useful enhancement to the module.

jb