perl-ldap-dev

RE: Netscape directory server console

[J B. <jb...@do...>]

the rules you need are to allow tcp over 2 ports--389 & whatever your admin
port is
also ICMP packets must be allowed through.

-----Original Message-----
From: per...@li...
[mailto:per...@li...]On Behalf Of
Lambright, Linda (N-Averstar)
Sent: Wednesday, March 21, 2001 9:01 PM
To: per...@li...
Subject: Netscape directory server console



	I know this isn't exactly a perl ldap question but if someone knows
the answer it would be a great deal of help

	When you use the netscape console to administer the directory server
over the administration port what protocol are you using.
	The reason I ask is I need to have the administration port opened in
the firewall for the correct protocol.

	Thank you in advance

	Linda Lambright

Netscape directory server console

[Lambright, L. (N-Averstar) <lin...@lm...>]

	I know this isn't exactly a perl ldap question but if someone knows
the answer it would be a great deal of help

	When you use the netscape console to administer the directory server
over the administration port what protocol are you using.
	The reason I ask is I need to have the administration port opened in
the firewall for the correct protocol.

	Thank you in advance

	Linda Lambright

Re: specifying value on entry->delete()

[<ma...@mj...>]

the delete() function is for deleting entire entries, not attribute 
values.

If you want to delete attribute values you must use the modify 
function.

I think it's like:
$ldap->modify($dn,delete => {attribute = value});

normally a password mod is in the form of a replace:
$ldap->modify($dn,replace => {password_attribute = value});

Mark
On 19 Mar 01, at 17:56, Danny Howard wrote:

> Net::LDAP folk!
> 
> I am trying to see if I can set Active Directory passwords via LDAP. 
> Of course, Microsoft do it their own way, but they document it at
> http://support.microsoft.com/support/kb/articles/Q269/1/90.ASP
> 
> It boils down to, you delete your old unicodePwd attribute, including
> your old password as a BER encoded string.  Then you add a new
> unicodePwd attribute, with the new password as a BER encoded string.
> 
> Cute.
> 
> But not for me:
> 
> [...]
> my $entry = Net::LDAP::Entry->new();
> 
> my $opass_ber = new Convert::BER;
> my $npass_ber = new Convert::BER;
> 
> $opass_ber->encode(STRING=>"\"$opass\"",);
> $npass_ber->encode(STRING=>"\"$npass\"",);
> 
> $entry->dn("cn=$user,$ldap_base");
> $entry->delete('unicodePwd' => $opass);
> $entry->add('unicodePwd' => $npass);
> my $return = $entry->update( $conn );
> 
> if( $return->done ) { die "return: " . $return->error . "\n"; }
> 
> 1-17:51 dannyman@noneedto ~> bin/adpasswd bobo zzzzzzzz bo69
> Can't use string ("zzzzzzzz") as an ARRAY ref while "strict refs" in
> use at /usr/local/lib/perl5/site_perl/5.005/Net/LDAP/Entry.pm line
> 179.
> 
> I'm not understanding quite how LDAP works at such a low level, my
> GUESS is that the delete() function of Net::LDAP::Entry does not
> support passing a value.
> 
> Comparing the delete() and add() subroutines in Entry.pm, it looks
> like the delete() function looks much like add() except that it adds a
> few checks ... what these checks are, I do not grok, but the evil line
> is the last in this paragraph:
> 
>     if (defined($val) and (!ref($val) or @$val)) {
>       my %values;
>       @values{@$val} = ();
> 
> My curiosity is that, is there a simple way to tell delete() to
> support specifying the value of the attribute to delete, and is this
> what I really want? :)
> 
> Thanks,
> -danny
> 
> 
> 


Mark Wilcox
ma...@mj...
Got LDAP?

specifying value on entry->delete()

[Danny H. <dan...@te...>]

Net::LDAP folk!

I am trying to see if I can set Active Directory passwords via LDAP.  Of
course, Microsoft do it their own way, but they document it at
http://support.microsoft.com/support/kb/articles/Q269/1/90.ASP

It boils down to, you delete your old unicodePwd attribute, including your old
password as a BER encoded string.  Then you add a new unicodePwd attribute,
with the new password as a BER encoded string.

Cute.

But not for me:

[...]
my $entry = Net::LDAP::Entry->new();

my $opass_ber = new Convert::BER;
my $npass_ber = new Convert::BER;

$opass_ber->encode(STRING=>"\"$opass\"",);
$npass_ber->encode(STRING=>"\"$npass\"",);

$entry->dn("cn=$user,$ldap_base");
$entry->delete('unicodePwd' => $opass);
$entry->add('unicodePwd' => $npass);
my $return = $entry->update( $conn );

if( $return->done ) { die "return: " . $return->error . "\n"; }

1-17:51 dannyman@noneedto ~> bin/adpasswd bobo zzzzzzzz bo69
Can't use string ("zzzzzzzz") as an ARRAY ref while "strict refs" in use at /usr/local/lib/perl5/site_perl/5.005/Net/LDAP/Entry.pm line 179.

I'm not understanding quite how LDAP works at such a low level, my GUESS
is that the delete() function of Net::LDAP::Entry does not support
passing a value.

Comparing the delete() and add() subroutines in Entry.pm, it looks like
the delete() function looks much like add() except that it adds a few
checks ... what these checks are, I do not grok, but the evil line is
the last in this paragraph:

    if (defined($val) and (!ref($val) or @$val)) {
      my %values;
      @values{@$val} = ();

My curiosity is that, is there a simple way to tell delete() to support
specifying the value of the attribute to delete, and is this what I
really want? :)

Thanks,
-danny

$ldap->modify question

[Mark M. <ma...@op...>]

I'm using perl-ldap-0.22 and I've notice something strange in my logs when I 
modify an entry. I'm using MessagingDirect LDAP/X500 product for my directory 
server.


$ldap->modify($dn, replace => { 'generationQualifier' => 'JR' });

If the 'generationQualifier' attribute doesn't exist, the logs show a successful 
modify to this entry. Not a problem.


$ldap->modify($dn, replace => { 'generationQualifier' => [] });

If the 'generationQualifier' attribute exists, the logs show a successful modify 
to this entry. Again, not a problem.


$ldap->modify($dn, replace => { 'generationQualifier' => 'SR' });

If the 'generationQualifier' attribute exists, the log first shows an "Error 
sent: Attribute" for the first attempt modify, followed by a successful modify 
to the record. 

I have not turned on full logging to see exactly what is being attempted twice 
and why the first always fails and the second succeeds. I wanted to see if 
anyone can tell me what the "ldap->modify replace" option is actually doing 
behind the scenes. I don't have a test server running so turning on the full 
logging on our production server is my last resort.


Any feedback would be greatly appreciated. Thanks.



Mark Murphy                          Wayne State University
Lead Applications Technical Analyst  Computing & Information Technology (C&IT)
(313) 577-4795 Voice                 Internet Services (IS)
(313) 577-8787 Fax                   5425 Woodward Ave.
                                     Detroit,  MI.   48202

Email: aa...@wa...
WWW  : http://www.wayne.edu/


------------- End Forwarded Message -------------


Mark Murphy                          Wayne State University
Lead Applications Technical Analyst  Computing & Information Technology (C&IT)
(313) 577-4795 Voice                 Internet Services (IS)
(313) 577-8787 Fax                   5425 Woodward Ave.
                                     Detroit,  MI.   48202

Email: aa...@wa...
WWW  : http://www.wayne.edu/

Re: Net::LDAP::Util::canonical_dn

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

Chris Ridd <chr...@me...> wrote:
> Graham Barr <gb...@po...> wrote:
>> On Thu, Mar 15, 2001 at 12:00:19PM -0600, Clif Harden wrote:
>>> It may be the easy way out, but I think it is the best option. It gives
>>> the user the choice on how the data is present back to him.
>> 
>> I agree.
>> 
>>> > What default should we have? ;-) We'd want to preserve the existing
>>> > interface (I guess) so we need a default.
>>> 
>>> 
>>> I think the default should be the current way perl-ldap handles the
>>> data, encode => none.  If the user does not care about encoding no
>>> changes to his software would be needed.
>>> 
>>> If the user wants the canonicalizer, encode => canonical.
>>> If the user wants base 64, encode => base64.  Would this require the
>>> perl base64 module?
>>> 
>>> 
>>> I have no idea how much coding work this would be.
>> 
>> 
>> this seems quite reasonable, and would not be too difficult to do.
> 
> OK.

I've added support for setting this behaviour in the constructor (and
documented it). The revised revised (:-) patch is attached.

Cheers,

Chris

Re: Net::LDAP::Util::canonical_dn

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

Graham Barr <gb...@po...> wrote:
> On Thu, Mar 15, 2001 at 12:00:19PM -0600, Clif Harden wrote:
>> It may be the easy way out, but I think it is the best option. It gives
>> the user the choice on how the data is present back to him.
> 
> I agree.
> 
>> > What default should we have? ;-) We'd want to preserve the existing
>> > interface (I guess) so we need a default.
>> 
>> 
>> I think the default should be the current way perl-ldap handles the data,
>> encode => none.  If the user does not care about encoding no changes
>> to his software would be needed.
>> 
>> If the user wants the canonicalizer, encode => canonical.
>> If the user wants base 64, encode => base64.  Would this require the perl
>> base64 module?
>> 
>> 
>> I have no idea how much coding work this would be.
> 
> 
> this seems quite reasonable, and would not be too difficult to do.

OK.

>> As I was writing this message I thought of something we need
>> to comprehend.
>> 
>> Mark Wilcox put dumping data in XML format, how is our encoding 
>> going to affect these methods.  I am sure we will need to add 
>> attribute tags specifing the encoding method used on the data
>> if the data is encoded.  
> 
> In DSML the DN is base64 encoded if it contains special characters
> and then it is flagged as such (IIRC).

I don't think that changing the LDIF export will (or should) affect the
DSML export. Except possibly we might want to add a similar 'encode'
argument to DSML::new(). But I'm not sure what we might let people encode
to, and since people who don't pay money to Oasis aren't now permitted to
participate in fixing the bugs in the DSML spec (grr) I really don't know
what to suggest.

I'm sure you can also use the normal SGML/XML entity names for special
characters, like &amp; and &lt; and so on. Or even &#nn;. (Just committed a
trivial fix to the DSML code that does this normalization, btw.)

> Graham.

Cheers,

Chris

Re: Net::LDAP::Util::canonical_dn

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

On Thu, Mar 15, 2001 at 12:00:19PM -0600, Clif Harden wrote:
> It may be the easy way out, but I think it is the best option. It gives
> the user the choice on how the data is present back to him.

I agree.

> > What default should we have? ;-) We'd want to preserve the existing
> > interface (I guess) so we need a default.
> 
> 
> I think the default should be the current way perl-ldap handles the data,
> encode => none.  If the user does not care about encoding no changes
> to his software would be needed.
> 
> If the user wants the canonicalizer, encode => canonical.
> If the user wants base 64, encode => base64.  Would this require the perl
> base64 module?
> 
> 
> I have no idea how much coding work this would be.


this seems quite reasonable, and would not be too difficult to do.

> As I was writing this message I thought of something we need
> to comprehend.
> 
> Mark Wilcox put dumping data in XML format, how is our encoding 
> going to affect these methods.  I am sure we will need to add 
> attribute tags specifing the encoding method used on the data
> if the data is encoded.  

In DSML the DN is base64 encoded if it contains special characters
and then it is flagged as such (IIRC).

Graham.


> 
> 
> Since I forgot to copy the perl-ldap list on my first response to you,
> I have included the perl-ldap list on this reply.
> 
> Regards,
> 
> Clif 
> 
> 

Re: Net::LDAP::Util::canonical_dn

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

> 
> Clif Harden <cl...@di...> wrote:
> >> 
> >> "Kurt D. Zeilenga" <Ku...@Op...> wrote:
> >> > I'm not sure this discussion applies to presentation of
> >> > server returned results in LDIFv1, but I suggest that when
> >> > presenting search results in LDIF entry format that the
> >> > returned DN be presented "as is" if possible, otherwise
> >> > base64 encoded.  It's kind of nasty for APIs to muck with
> >> > returned values without applications specifically
> >> > asking for such mucking.
> >> > 
> >> > Kurt
> >> > 
> >> 
> >> OK, that's a vote for base-64 encoding, which was what I was doing
> >> originally. Graham thinks keeping the DNs readable is more important.
> >> 
> >> Does anyone else have other comments?
> >> 
> >> Cheers,
> >> 
> >> Chris
> >> 
> >> 
> > 
> 
> Hi Clif,


Hi!


> 
> > I prefer the following.
> > 
> > If the DN is readable then the DN is printed as a readable string, 
> > if the DN has unreadable characters in it then printed as an
> > encoded string.
> 
> OK, assuming the LDIF interpretation (or stricter) of 'readable'. But how
> do we encode it, using the canonicalizer, or a simpler and less 'damaging'
> base64 encode?


Most of the tools I use encode in base64.  I do not know what to say
about a DN canonicalizer just yet, I know that it is needed.


> 
> > How about giving the user an encode option. 
> 
> That's the easy way out :-)

It may be the easy way out, but I think it is the best option. It gives
the user the choice on how the data is present back to him.

> 
> What default should we have? ;-) We'd want to preserve the existing
> interface (I guess) so we need a default.


I think the default should be the current way perl-ldap handles the data,
encode => none.  If the user does not care about encoding no changes
to his software would be needed.

If the user wants the canonicalizer, encode => canonical.
If the user wants base 64, encode => base64.  Would this require the perl
base64 module?


I have no idea how much coding work this would be.


As I was writing this message I thought of something we need
to comprehend.

Mark Wilcox put dumping data in XML format, how is our encoding 
going to affect these methods.  I am sure we will need to add 
attribute tags specifing the encoding method used on the data
if the data is encoded.  


Since I forgot to copy the perl-ldap list on my first response to you,
I have included the perl-ldap list on this reply.

Regards,

Clif 

Re: Net::LDAP::Util::canonical_dn

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

"Kurt D. Zeilenga" <Ku...@Op...> wrote:
> I'm not sure this discussion applies to presentation of
> server returned results in LDIFv1, but I suggest that when
> presenting search results in LDIF entry format that the
> returned DN be presented "as is" if possible, otherwise
> base64 encoded.  It's kind of nasty for APIs to muck with
> returned values without applications specifically
> asking for such mucking.
> 
> Kurt
> 

OK, that's a vote for base-64 encoding, which was what I was doing
originally. Graham thinks keeping the DNs readable is more important.

Does anyone else have other comments?

Cheers,

Chris

Re: Perldap referral problem

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

eri...@hk... wrote:
> I tried to stop PerLDAP following referrals during search by
> using the API
> $host = "172.15.207.46";
> $port = "389";
> $ld = ldap_init($host,$port);
> $status = ldap_set_option($ld,LDAP_OPT_REFERRALS,0);
> $status = ldap_get_option($ld,LDAP_OPT_REFERRALS,$opt);
> print ("$status -- option = $opt\n");
> 
> The problem I got are
> (1) The LDAP_OPT_REFFERALS is still ON (that is one) after the call.
> (2) LDAP_OPT_OFF cannot be used. The error is
> Can't locate auto/Mozilla/LDAP/API/LDAP_OPT_OF.al in
> @INC <@INC contains: C:/Perl/lib C:/Perl/site/lib .>
> at option.plx line 40
> 
> However, other constants defined in API are available such as
> LDAP_OPT_ON, LDAP_SUCCESS, LDAP_VERSION3 etc.
> 
> As a reult, I got the value of LDAP_OPT_OFF (that is zero) from the api.pm
> and hard coded it in the API call.
> 
> Your help is sought.
> 
> ______________________________________________________________________
> 
> This message is intended only for use of the addressee and may  contain
> information that is privileged and confidential. If you are not the
> intended recipient, you are hereby notified that any use or dissemination
> of this communication is strictly prohibited. If you have received this
> communication in error, please notify us immediately by reply and delete
> this message from your system.
> 
> 

This is the list for the perl-ldap module (providing Net::LDAP), and you
need to talk to the maintainers (are there any?) of the confusingly
misnamed perldap module (providing Mozilla::LDAP).

Cheers,

Chris

Perldap referral problem

[<eri...@hk...>]

I tried to stop PerLDAP following referrals during search by
using the API
$host = "172.15.207.46";
$port = "389";
$ld = ldap_init($host,$port);
$status = ldap_set_option($ld,LDAP_OPT_REFERRALS,0);
$status = ldap_get_option($ld,LDAP_OPT_REFERRALS,$opt);
print ("$status -- option = $opt\n");

The problem I got are
(1) The LDAP_OPT_REFFERALS is still ON (that is one) after the call.
(2) LDAP_OPT_OFF cannot be used. The error is
Can't locate auto/Mozilla/LDAP/API/LDAP_OPT_OF.al in
@INC <@INC contains: C:/Perl/lib C:/Perl/site/lib .>
at option.plx line 40

However, other constants defined in API are available such as
LDAP_OPT_ON, LDAP_SUCCESS, LDAP_VERSION3 etc.

As a reult, I got the value of LDAP_OPT_OFF (that is zero) from the api.pm
and hard coded it in the API call.

Your help is sought.

______________________________________________________________________

This message is intended only for use of the addressee and may  contain
information that is privileged and confidential. If you are not the intended
recipient, you are hereby notified that any use or dissemination of this
communication is strictly prohibited. If you have received this communication in
error, please notify us immediately by reply and delete this message from your
system.

[Fwd] Net::LDAP Idea

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

----- Forwarded message from Christoph Neumann <en...@ap...> -----

Date: Tue, 13 Mar 2001 20:24:07 -0800 (PST)
To: Graham Barr <gb...@po...>
From: Christoph Neumann <en...@ap...>
Subject: Net::LDAP Idea

Graham,

I'm a developer at Azusa Pacific University.  We are using the Net::LDAP
library.  I think the API is quite well laid out and well designed.  You
have good documentation too.

However, I noticed one issue with the library.  We have a large directories
of user information.  Sometimes I need to pull about 5000 entries out of
LDAP at once.  I noticed that the script would slowly grow to about 120+ MB
of RAM.  I tried using a callback to see if the search function does not
allocate memory to the internal buffer in that case, but I noticed that it
still does.  I then check the code for searching function and noticed that
is will always add each entry to the internal list.

Here is a suggesstion...
Allow the user to set a flag specifying whether or not they want to keep a
list of all the returned entries in the internal array.  This is good for
processing huge amounts of data (100's of MBs).  The callback can handle
each data item as it comes and then search function can just throw the data
away.

I wanted to see what you think since you developed the code and understand
it the best.  I would be willing to contribute some time to implementing
the feature if necessary.

Thanks,
Christoph Neumann



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

Re: Net::LDAP::Util::canonical_dn

[Kurt D. Z. <Ku...@Op...>]

I'm not sure this discussion applies to presentation of
server returned results in LDIFv1, but I suggest that when
presenting search results in LDIF entry format that the
returned DN be presented "as is" if possible, otherwise
base64 encoded.  It's kind of nasty for APIs to muck with
returned values without applications specifically
asking for such mucking.

Kurt

Re: LDIF.pm patch -- print modrdn in write_cmd()

[Kartik S. <sub...@co...>]

Chris Ridd wrote:
> 
> Kartik Subbarao <sub...@co...> wrote:
> > I have submitted a patch to LDIF.pm via sourceforge. It enables
> > write_cmd() to print modrdn operations properly.
> >
> >        -Kartik
> >
> 
> It doesn't handle newsuperior...

[...]

Thanks for the enhancements Chris! Interesting discussion about base64
vs escaping the DN, I hadn't even considered that. Looks like you guys
have got it well in hand.

	-Kartik

Re: Net::LDAP::Util::canonical_dn

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

Graham Barr <gb...@po...> wrote:
> On Thu, Mar 08, 2001 at 12:45:42PM -0000, Chris Ridd wrote:
>> Graham Barr <gb...@po...> wrote:
>> > On Thu, Mar 08, 2001 at 11:04:06AM -0000, Chris Ridd wrote:
>> > 
>> >> Let's see, what canonicalisation does canonical_dn do..
>> >> 
>> >> * it lowercases values that are # followed by hex,
>> >> * it lowercases types that start with an OID,
> 
> Actually it removes the leading oid. caharacters if the type is
> an oid
> 
>> It also upper-cases attribute types.
> 
> Yes.
> 
>> I reckon it would be OK to call canonicalise_dn in the LDIF _write_cmd,
>> but perhaps only in the case where the DN has a char that is not a
>> 'SAFE-UTF8-CHAR', as per RFC 2849.
> 
> Well as we don't really handle UTF8 that wee yet (because perl does not
> either) I will go with the regexp [\x00-\x1f\x7f-\xff]
> 
> Graham.
> 

OK. The attached patch does the moddn stuff from Kartik, adds newsuperior
functionality, and canonicalises DNs when they are 'unsafe'.

Sing out anyone if they can see a dreadful flaw in this; otherwise I'll
integrate it in a couple of days.

Cheers,

Chris

$ldap->moddn question

[Mark M. <ma...@op...>]

I'm using perl-ldap-0.22 and I'm having problems with the moddn option 
newsuperior.

Can anyone give me more information on this option? Is it operational in version 
0.22? What exactly does this do?

Based on what I've looked at for moddn, it allows you to rename the RDN for an 
entry but also move it to a new location.

Any feedback would be greatly appreciated. Thanks.




Mark Murphy                          Wayne State University
Lead Applications Technical Analyst  Computing & Information Technology (C&IT)
(313) 577-4795 Voice                 Internet Services (IS)
(313) 577-8787 Fax                   5425 Woodward Ave.
                                     Detroit,  MI.   48202

Email: aa...@wa...
WWW  : http://www.wayne.edu/

Re: Net::LDAP::Util::canonical_dn

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

On Thu, Mar 08, 2001 at 12:45:42PM -0000, Chris Ridd wrote:
> Graham Barr <gb...@po...> wrote:
> > On Thu, Mar 08, 2001 at 11:04:06AM -0000, Chris Ridd wrote:
> > 
> >> Let's see, what canonicalisation does canonical_dn do..
> >> 
> >> * it lowercases values that are # followed by hex,
> >> * it lowercases types that start with an OID,

Actually it removes the leading oid. caharacters if the type is
an oid

> It also upper-cases attribute types.

Yes.

> I reckon it would be OK to call canonicalise_dn in the LDIF _write_cmd, but
> perhaps only in the case where the DN has a char that is not a
> 'SAFE-UTF8-CHAR', as per RFC 2849.

Well as we don't really handle UTF8 that wee yet (because perl does not either)
I will go with the regexp [\x00-\x1f\x7f-\xff]

Graham.

Re: Net::LDAP::Util::canonical_dn

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

Graham Barr <gb...@po...> wrote:
> On Thu, Mar 08, 2001 at 11:04:06AM -0000, Chris Ridd wrote:
> 
>> Let's see, what canonicalisation does canonical_dn do..
>> 
>> * it lowercases values that are # followed by hex,
>> * it lowercases types that start with an OID,
>> * it backslashifies RFC 2253-magic characters,
>> * it backslash and hex encodes 0x00-0x1f and 0x7f-0xff characters,
>> * it surrounds values with leading/trailing/multiple spaces with quotes.
>> 
>> (Actually, that last part is not permitted by RFC 2253. You should
>> replace those spaces with "\20" or "\ ". I suspect "\20" would be safer
>> especially at the end of a string, to avoid someone simply ripping
>> trailing spaces off and leaving the string ending with a dangling slash.)
> 
> 2253 also no longer requires the escaping of multiple spaces within
> a value.

Yes, that appears to be an RFC 1779-ism.

>> Those canonicalisations look OK to me. Have I missed any others?
> 
> canonical_dn also reorders the parts of multi-part RDNs

So it does. I suspect this will be OK for most servers that support
multi-ava RDNs.

It also upper-cases attribute types.

> Graham.
> 

I reckon it would be OK to call canonicalise_dn in the LDIF _write_cmd, but
perhaps only in the case where the DN has a char that is not a
'SAFE-UTF8-CHAR', as per RFC 2849.

Cheers,

Chris

Net::LDAP::Util::canonical_dn

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

On Thu, Mar 08, 2001 at 11:04:06AM -0000, Chris Ridd wrote:

> Let's see, what canonicalisation does canonical_dn do..
> 
> * it lowercases values that are # followed by hex,
> * it lowercases types that start with an OID,
> * it backslashifies RFC 2253-magic characters,
> * it backslash and hex encodes 0x00-0x1f and 0x7f-0xff characters,
> * it surrounds values with leading/trailing/multiple spaces with quotes.
> 
> (Actually, that last part is not permitted by RFC 2253. You should replace
> those spaces with "\20" or "\ ". I suspect "\20" would be safer especially
> at the end of a string, to avoid someone simply ripping trailing spaces off
> and leaving the string ending with a dangling slash.)

2253 also no longer requires the escaping of multiple spaces within
a value.

> Those canonicalisations look OK to me. Have I missed any others?

canonical_dn also reorders the parts of multi-part RDNs

Graham.

Re: LDIF.pm patch -- print modrdn in write_cmd()

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

On Thu, Mar 08, 2001 at 11:04:06AM -0000, Chris Ridd wrote:
> Graham Barr <gb...@po...> wrote:
> > On Thu, Mar 08, 2001 at 09:50:45AM -0000, Chris Ridd wrote:
> >> Graham Barr <gb...@po...> wrote:
> >> > I don't think the DN should be base64 encoded, it should be encoded
> >> > using rules from rfc2253, which should result in a printable string
> >> > and avoid the need for base64 encoding

> >> So we need an extra bit of code to backslashify a DN.
> >> 
> >> 	my $dn = $entry->dn;
> >> 	$dn =~ s/([\x00-\x1f:<\x7f-\xff])/sprintf("\\%02x",ord($1))/ge;
> >> 

> > We could just do the above, or we could call the cannonify sub in ::Util
> > if /[\x00-\x1f\x7f-\xff]/ or is that too much is it could change the
> > way a DN looks
> 
> Let's see, what canonicalisation does canonical_dn do..
> 
> * it lowercases values that are # followed by hex,
> * it lowercases types that start with an OID,
> * it backslashifies RFC 2253-magic characters,
> * it backslash and hex encodes 0x00-0x1f and 0x7f-0xff characters,
> * it surrounds values with leading/trailing/multiple spaces with quotes.
> 
> (Actually, that last part is not permitted by RFC 2253. You should replace
> those spaces with "\20" or "\ ". I suspect "\20" would be safer especially
> at the end of a string, to avoid someone simply ripping trailing spaces off
> and leaving the string ending with a dangling slash.)

Hm, bust have been a leftover from the original implementation which
followed 1779, I will change it to use \20

> Those canonicalisations look OK to me. Have I missed any others?

I don't think so. So do you agree that we should do this for LDIF ?

And should we always call cannonify or only if there is a special
character in the DN ?

Graham.

Re: LDIF.pm patch -- print modrdn in write_cmd()

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

Graham Barr <gb...@po...> wrote:
> On Thu, Mar 08, 2001 at 09:50:45AM -0000, Chris Ridd wrote:
>> Graham Barr <gb...@po...> wrote:
>> > I don't think the DN should be base64 encoded, it should be encoded
>> > using rules from rfc2253, which should result in a printable string
>> > and avoid the need for base64 encoding
>> 
>> Interesting.
>> 
>> RFC 2849 says that DNs should be base-64 encoded if any of the RDN values
>> contain 'unsafe' characters.
>> 
>> RFC 2253 format DNs 'may' escape any character using the \hexpair
>> notation.
>> 
>> So what you're suggesting is that we display DNs by always
>> backslashifying unsafe characters instead of base-64 encoding them.
>> 
>> I think that RFC 2849 would permit that, and it does have the benefit of
>> making the DNs semi-readable. Well, more readable than a blob of base 64.
> 
> That was my reasoning behind it.

Uh huh.

>> So we need an extra bit of code to backslashify a DN.
>> 
>> 	my $dn = $entry->dn;
>> 	$dn =~ s/([\x00-\x1f:<\x7f-\xff])/sprintf("\\%02x",ord($1))/ge;
>> 
>> (NB colon and < are special in LDIF, hence the additions in the regex.)
> 
> They are only special if they are the first character though, which would
> not happen with a DN, right ?

Right.

> We could just do the above, or we could call the cannonify sub in ::Util
> if /[\x00-\x1f\x7f-\xff]/ or is that too much is it could change the
> way a DN looks

Let's see, what canonicalisation does canonical_dn do..

* it lowercases values that are # followed by hex,
* it lowercases types that start with an OID,
* it backslashifies RFC 2253-magic characters,
* it backslash and hex encodes 0x00-0x1f and 0x7f-0xff characters,
* it surrounds values with leading/trailing/multiple spaces with quotes.

(Actually, that last part is not permitted by RFC 2253. You should replace
those spaces with "\20" or "\ ". I suspect "\20" would be safer especially
at the end of a string, to avoid someone simply ripping trailing spaces off
and leaving the string ending with a dangling slash.)

Those canonicalisations look OK to me. Have I missed any others?

Cheers,

Chris

Re: LDIF.pm patch -- print modrdn in write_cmd()

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

On Thu, Mar 08, 2001 at 09:50:45AM -0000, Chris Ridd wrote:
> Graham Barr <gb...@po...> wrote:
> > I don't think the DN should be base64 encoded, it should be encoded
> > using rules from rfc2253, which should result in a printable string
> > and avoid the need for base64 encoding
> 
> Interesting.
> 
> RFC 2849 says that DNs should be base-64 encoded if any of the RDN values
> contain 'unsafe' characters.
> 
> RFC 2253 format DNs 'may' escape any character using the \hexpair notation.
> 
> So what you're suggesting is that we display DNs by always backslashifying
> unsafe characters instead of base-64 encoding them.
> 
> I think that RFC 2849 would permit that, and it does have the benefit of
> making the DNs semi-readable. Well, more readable than a blob of base 64.

That was my reasoning behind it.

> So we need an extra bit of code to backslashify a DN.
> 
> 	my $dn = $entry->dn;
> 	$dn =~ s/([\x00-\x1f:<\x7f-\xff])/sprintf("\\%02x",ord($1))/ge;
> 
> (NB colon and < are special in LDIF, hence the additions in the regex.)

They are only special if they are the first character though, which would
not happen with a DN, right ?

We could just do the above, or we could call the cannonify sub in ::Util
if /[\x00-\x1f\x7f-\xff]/ or is that too much is it could change the
way a DN looks

Graham.

Re: one level scope

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

ma...@mj... wrote:
> Ok,
> I have a question on scope. It's been so long since I had to do a 
> one level scope search and I don't have an active LDAP server 
> handy to test it out.
> 
> I thought a one level search, searches all entries under a base 
> entry, including their children but not the base entry.
> 
> But now I've heard that it only searches one level, that level under 
> the base but not their children.
> 
> ie:
> given a tree of:
> o=airius.com
>    ou=people,o=airius.com
>  uid=...,ou=people,o=airius.com
>   ...
> one level with a search base of o=airius.com, would only search 
> the ou=people entries?
> 
> thanks,
> 
> Mark
>  
> Mark Wilcox
> ma...@mj...
> Got LDAP?
> 

X.511 10.2.2 (Search arguments) says that base scope means just the
baseObject, oneLevel scope means all the *immediate* subordinates but not
the baseObject or any of the baseObject's grandchildren, and subtree scope
means the baseObject and all subordinates.

RFC 2251 4.5 (Search Operation) says roughly the same thing.

So I think you heard right.

Cheers,

Chris

Re: LDIF.pm patch -- print modrdn in write_cmd()

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

Graham Barr <gb...@po...> wrote:
> I don't think the DN should be base64 encoded, it should be encoded
> using rules from rfc2253, which should result in a printable string
> and avoid the need for base64 encoding

Interesting.

RFC 2849 says that DNs should be base-64 encoded if any of the RDN values
contain 'unsafe' characters.

RFC 2253 format DNs 'may' escape any character using the \hexpair notation.

So what you're suggesting is that we display DNs by always backslashifying
unsafe characters instead of base-64 encoding them.

I think that RFC 2849 would permit that, and it does have the benefit of
making the DNs semi-readable. Well, more readable than a blob of base 64.

So we need an extra bit of code to backslashify a DN.

	my $dn = $entry->dn;
	$dn =~ s/([\x00-\x1f:<\x7f-\xff])/sprintf("\\%02x",ord($1))/ge;

(NB colon and < are special in LDIF, hence the additions in the regex.)

Cheers,

Chris