perl-ldap-dev

Re: canonical_dn

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

On Wed, Jan 09, 2002 at 08:28:08AM -0000, Chris Ridd wrote:
> Graham Barr <gb...@po...> wrote:
> > On Sun, Jan 06, 2002 at 01:57:37PM +0100, Peter Marschall wrote:
> >> Sorry, 
> >> 
> >> a few small errors in my last mail's listings.
> >> Here's the corrected version
> > 
> > Can you get it so that it will pass the t/01canon.t testcase ? Also can
> > explode_dn share the same code ?
> > 
> > Graham.
> > 
> > 
> 
> There are some other DN test cases at:
> 
> 	<http://www.openldap.org/ietf/ldapbis/dn.txt>

There is also a filter.txt in the same directory, which has found a few
issues in our implementation.

Graham.

Re: canonical_dn

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

On Wed, Jan 09, 2002 at 03:56:21PM -0000, Chris Ridd wrote:
> Graham Barr <gb...@po...> wrote:
> > On Wed, Jan 09, 2002 at 08:28:08AM -0000, Chris Ridd wrote:
> >> Graham Barr <gb...@po...> wrote:
> >> > On Sun, Jan 06, 2002 at 01:57:37PM +0100, Peter Marschall wrote:
> >> >> Sorry, 
> >> >> 
> >> >> a few small errors in my last mail's listings.
> >> >> Here's the corrected version
> >> > 
> >> > Can you get it so that it will pass the t/01canon.t testcase ? Also can
> >> > explode_dn share the same code ?
> >> > 
> >> > Graham.
> >> > 
> >> > 
> >> 
> >> There are some other DN test cases at:
> >> 
> >> 	<http://www.openldap.org/ietf/ldapbis/dn.txt>
> > 
> > Thanks,
> > 
> > After adding those the only failure we have is in accepting the following
> > bad DNs, although I am not convinced that they are all bad.
> > 
> > OID.1.1=jsmith // invalid attribute type name
> > 
> >   why ? is 1.1 an invalid OID ?
> 
> OIDs in attribute types don't have an "OID." prefix.
> 
> The DN should be "1.1=jsmith"
> 
> The BNF in RFC 2253 doesn't permit "." in attribute types unless the entire
> attribute type is an OID.
> 
> It is a valid OID, but defined by X.208 to not exist.

From RFC2253

4.  Relationship with RFC 1779 and LDAPv2

...

   Implementations MUST allow an oid in the attribute type to be
   prefixed by one of the character strings "oid." or "OID.".

...

So IMO, it is valid to accept it, but not generate it. The oid. prefix
is simply ignored.


Graham.

> 
> > UID=jsmith, DC=example, DC=net // spaces
> > 
> >   I dont think this is bad. Th RFC states that you should accept spaces
> > around the ,s
> 
> Agreed. It is bad in the sense that an implementation shouldn't generate
> it, but it must be able to parsed it.
> 
> > UID=jsmith;DC=example;DC=net  // semi-colons
> > 
> >   The RFC states that implementations should allow for the use of a ;
> >   instead of a ,
> 
> Ditto.
> 
> > 
> > CN="John Smith",DC=example,DC=net  // quotes
> > 
> >   Again, the RFC states that values may be surrounded with "s
> 
> Ditto.
> 
> > 01.1=jsmith // invalid numeric OID
> > 
> >   This one could be easily fixed as we just change \d+ to [0-9]\d*
> >   but I dont really feel the need.
> 
> Given the number of DNs containing OIDs as attribute types (approx 0) I
> concur.
> 
> > Graham.
> > 
> 
> Cheers,
> 
> Chris
> 

Re: canonical_dn

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

Graham Barr <gb...@po...> wrote:
> On Wed, Jan 09, 2002 at 08:28:08AM -0000, Chris Ridd wrote:
>> Graham Barr <gb...@po...> wrote:
>> > On Sun, Jan 06, 2002 at 01:57:37PM +0100, Peter Marschall wrote:
>> >> Sorry, 
>> >> 
>> >> a few small errors in my last mail's listings.
>> >> Here's the corrected version
>> > 
>> > Can you get it so that it will pass the t/01canon.t testcase ? Also can
>> > explode_dn share the same code ?
>> > 
>> > Graham.
>> > 
>> > 
>> 
>> There are some other DN test cases at:
>> 
>> 	<http://www.openldap.org/ietf/ldapbis/dn.txt>
> 
> Thanks,
> 
> After adding those the only failure we have is in accepting the following
> bad DNs, although I am not convinced that they are all bad.
> 
> OID.1.1=jsmith // invalid attribute type name
> 
>   why ? is 1.1 an invalid OID ?

OIDs in attribute types don't have an "OID." prefix.

The DN should be "1.1=jsmith"

The BNF in RFC 2253 doesn't permit "." in attribute types unless the entire
attribute type is an OID.

It is a valid OID, but defined by X.208 to not exist.

> UID=jsmith, DC=example, DC=net // spaces
> 
>   I dont think this is bad. Th RFC states that you should accept spaces
> around the ,s

Agreed. It is bad in the sense that an implementation shouldn't generate
it, but it must be able to parsed it.

> UID=jsmith;DC=example;DC=net  // semi-colons
> 
>   The RFC states that implementations should allow for the use of a ;
>   instead of a ,

Ditto.

> 
> CN="John Smith",DC=example,DC=net  // quotes
> 
>   Again, the RFC states that values may be surrounded with "s

Ditto.

> 01.1=jsmith // invalid numeric OID
> 
>   This one could be easily fixed as we just change \d+ to [0-9]\d*
>   but I dont really feel the need.

Given the number of DNs containing OIDs as attribute types (approx 0) I
concur.

> Graham.
> 

Cheers,

Chris

Re: canonical_dn

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

On Wed, Jan 09, 2002 at 08:28:08AM -0000, Chris Ridd wrote:
> Graham Barr <gb...@po...> wrote:
> > On Sun, Jan 06, 2002 at 01:57:37PM +0100, Peter Marschall wrote:
> >> Sorry, 
> >> 
> >> a few small errors in my last mail's listings.
> >> Here's the corrected version
> > 
> > Can you get it so that it will pass the t/01canon.t testcase ? Also can
> > explode_dn share the same code ?
> > 
> > Graham.
> > 
> > 
> 
> There are some other DN test cases at:
> 
> 	<http://www.openldap.org/ietf/ldapbis/dn.txt>

Thanks,

After adding those the only failure we have is in accepting the following
bad DNs, although I am not convinced that they are all bad.

OID.1.1=jsmith // invalid attribute type name

  why ? is 1.1 an invalid OID ?

UID=jsmith, DC=example, DC=net // spaces

  I dont think this is bad. Th RFC states that you should accept spaces around the ,s

UID=jsmith;DC=example;DC=net  // semi-colons

  The RFC states that implementations should allow for the use of a ;
  instead of a ,


CN="John Smith",DC=example,DC=net  // quotes

  Again, the RFC states that values may be surrounded with "s

01.1=jsmith // invalid numeric OID

  This one could be easily fixed as we just change \d+ to [0-9]\d*
  but I dont really feel the need.

Graham.

Re: canonical_dn

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

Graham Barr <gb...@po...> wrote:
> On Sun, Jan 06, 2002 at 01:57:37PM +0100, Peter Marschall wrote:
>> Sorry, 
>> 
>> a few small errors in my last mail's listings.
>> Here's the corrected version
> 
> Can you get it so that it will pass the t/01canon.t testcase ? Also can
> explode_dn share the same code ?
> 
> Graham.
> 
> 

There are some other DN test cases at:

	<http://www.openldap.org/ietf/ldapbis/dn.txt>

Cheers,

Chris

Re: canonical_dn

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

On Tue, Jan 08, 2002 at 06:19:44PM +0000, Graham Barr wrote:
> On Sun, Jan 06, 2002 at 01:57:37PM +0100, Peter Marschall wrote:
> > Sorry, 
> > 
> > a few small errors in my last mail's listings.
> > Here's the corrected version
> 
> Can you get it so that it will pass the t/01canon.t testcase ? Also can
> explode_dn share the same code ?

I already did :). This is what I got.

Graham.



## split a DN string into its parts
# Synopsis:  @rdns = split_dn($dn, %optionHash)
# allowed options:
#  * lowercase: convert attribute names to lower case
#  * uppercase: convert attribute names to upper case
#  * sort_rdn: sort RDN values
#  * split_rdn: split multi part RDNs into their parts
sub split_dn($%) {
  my $dn = shift;
  my %opt = @_;
  my (@dn, @rdn);

  $dn = $dn->dn if ref($dn);

  while ($dn =~ /\G(?:
                \s*
                ([a-zA-Z][-a-zA-Z0-9]*|(?:[Oo][Ii][Dd]\.)?\d+(?:\.\d+)*)
                \s*
                =
                \s*
                (
                  (?:[^\\",=+<>\#;]*[^\\",=+<>\#;\s]|\\(?:[\\ ",=+<>#;]|[0-9a-fA-F]{2}))*
		  |
                  \#(?:[0-9a-fA-F]{2})+
		  |
                  "(?:[^\\"]+|\\(?:[\\",=+<>#;]|[0-9a-fA-F]{2}))*"
                )
                \s*
                (?:([;,+])\s*(?=\S)|$)
                )\s*/gcx)
  {
    my ($type,$val,$sep) = ($1,$2,$3);

    $type =~ s/^oid\.(\d+(\.\d+)*)$/$1/i;
    $type = lc($type)  if $opt{lowercase};
    $type = uc($type)  if $opt{uppercase};

    if ($val !~ /^#/) {
      $val =~ s/^"(.*)"$/$1/;
      $val =~ s/\\([\\ ",=+<>#;]|[0-9a-fA-F]{2})
               /length($1)==1 ? $1 : chr(hex($1))
               /xeg;
      $val =~ s/([\\",=+<>#;])/\\$1/g;
      $val =~ s/([\x00-\x1F])/sprintf("\\%02x",ord($1))/eg;

      $val =~ s/(^\s+|\s+$)/"\\20" x length $1/ge;
    }

    push @rdn, "$type=$val";

    unless (defined $sep and $sep eq '+') {
      @rdn = sort(@rdn)  if $opt{sort_rdn};
      push @dn, ($opt{split_rdn}) ?
                  ((scalar(@rdn) > 1) ? [ @rdn ] : ($rdn[0] || '')) :
                  join('+', @rdn);
      @rdn = ();
    }
  }
  
  (length($dn) != (pos($dn) || 0))
    ? wantarray ? ()  : undef
    : wantarray ? @dn : \@dn;
}


## join RDNs and RDN parts into a DN string ##
# Synopsis:  $dn = join_dn(@dnpartref, %optionhash)
sub join_dn(\@%) {
  my $dnparts = shift or return undef;
  my %opt = @_;
  my @dn = map {
    ref($_)
      ? join($opt{reversed} ? '\001' : '+', @$_)
      : $_
  } @$dnparts or return undef;

  $opt{reversed}
    ? join('\000', reverse @dn)
    : join(','   , @dn);
}

sub canonical_dn($;$) {
  my ($dn, $rev) = @_;

  $dn = $dn->dn if ref($dn);

  &join_dn(
    scalar split_dn($dn, uppercase => 1, split_rdn => 1, sort_rdn => 1),
    reversed => $rev
  );
}

Re: canonical_dn

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

On Sun, Jan 06, 2002 at 01:57:37PM +0100, Peter Marschall wrote:
> Sorry, 
> 
> a few small errors in my last mail's listings.
> Here's the corrected version

Can you get it so that it will pass the t/01canon.t testcase ? Also can
explode_dn share the same code ?

Graham.

Re: canonical_dn

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

On Sun, Jan 06, 2002 at 01:45:17PM +0100, Peter Marschall wrote:
> Hi,
> 
> i have tried to use canonical_dn with UTF 8 and I think
> it treats strings with UTF8 encoded values wrong.

It probably does.

> Characters with codes > 127 have UTF8 encodings that
> consist of 2 or more bytes that have all codes > 127.
> Since these characters are legal in LDAPv3 DNs they should
> not get escaped.

True, assuming the DN given is UTF8, which it should be with
LDAPv3 but not v2

But the escaping should be done on the basis of the character being
printable. Net::LDAP makes a bad assumption here.

> So line 310 of Net/LDAP/Util.pm should read
> 
>   $val =~ s/([\x00-\x1f])/sprintf("\\%02x",ord($1))/eg;
> 
> instead of the current version:
> 
>     $val =~ s/([\x00-\x1f\x7f-\xff])/sprintf("\\%02x",ord($1))/eg;
> 
> 
> When changing canonical_dn() anyway, maybe changing the 
> implementation into three functions would be helpful.
> It would give users of Net::LDAP a standardized way of dealing with 
> DNs and parts of it (very helpful when moving entries, ..) without having
> to reimplement the wheel themselves.

I have thought about this before, just never done it :)

> Here is my idea:

Looks good.

Graham.

> 
> 
> ## split a DN string into its parts; code stolen from canonical_dn() ##
> # Synopsis:  @rdns = splitDN($dn, %optionHash)
> # allowed options:
> #  * lowercase: convert attribute names to lower case
> #  * uppercase: convert attribute names to upper case
> #  * sortRDN: sort RDN values
> #  * splitRDN: split multi part RDNs into their parts
> sub splitDN($%)
> {
> my $dn = shift;
> my %opt = @_;
> my @dn;
> my @rdn;
> 
>  $dn = $dn->dn if ref($dn);
> 
>   while ($dn =~ /\G(?:
>                 \s*
>                 ([a-zA-Z][-a-zA-Z0-9]*|(?:[Oo][Ii][Dd]\.)?\d+(?:\.\d+)*)
>                 \s*
>                 =
>                 \s*
>                 (
>                   (?:[^\\",=+<>\#;]*[^\\",=+<>\#;\s]|\\(?:[\\ 
> ",=+<>#;]|[0-9a-fA-F]{2}))*
>                   |
>                   \#(?:[0-9a-fA-F]{2})+
>                   |
>                   "(?:[^\\"]+|\\(?:[\\",=+<>#;]|[0-9a-fA-F]{2}))*"
>                 )
>                 \s*
>                 (?:([;,+])\s*(?=\S)|$)
>                 )\s*/gcx)
>   {
>   my ($type,$val,$sep) = ($1,$2,$3);
> 
>     $type =~ s/^oid\.(\d+(\.\d+)*)$/$1/i;
>     $type = lc($type)  if ($opt{lowercase});
>     $type = uc($type)  if ($opt{uppercase});
> 
>     if ($val !~ /^#/)
>     {
>       $val =~ s/^"(.*)"$/$1/;
>       $val =~ s/\\([\\ ",=+<>#;]|[0-9a-fA-F]{2})
>                /length($1)==1 ? $1 : chr(hex($1))
>                /xeg;
>       $val =~ s/([\\",=+<>#;])/\\$1/g;
>       $val =~ s/([\x00-\x1F])/sprintf("\\%02x",ord($1))/eg;
> 
>       $val =~ s/(^\s+|\s+$)/"\\20" x length $1/ge;
>     }
> 
>     push @rdn, "$type=$val";
> 
>     unless (defined $sep and $sep eq '+')
>     {
>       @rdn = sort(@rdn)  if ($opt{sortRDN});
>       push @dn, ($opt{splitRDN}) ?
>                   ((scalar(@rdn) > 1) ? [ @rdn ] : ($rdn[0] || '')) :
>                   join('+', @rdn);
>       @rdn = ();
>     }
>   }
> 
>   return((length($dn) != (pos($dn) || 0)) ? () : @dn);
> }
> 
> 
> ## join RDNs and RDN parts into a DN string ##
> # Synopsis:  $dn = joinDN(@dnpartref, %optionhash)
> sub joinDN(\@%)
> {
> my @dnparts = @i{+shift};
> my %opt = @_;
> my $dn = '';
> 
>   @dnparts = reverse(@dnparts)  if ($opt{reversed});
> 
>   foreach my $part (@dnparts)
>   {
>     $dn .= (($opt{reversed}) ? \000 : ',')  if ($dn);
> 
>     if (ref($part))     # multi part RDN
>     {
>     my $partlist = ($opt{revered}) ? reverse(@$part) : @$part;
>     my $rdn;
> 
>       foreach my $rdnpart (@partlist)
>       {
>         return  if (!$rdnpart);
> 
>         $rdn .= (($opt{reversed}) ? \001 : '+')  if ($rdn);
>         $rdn .= $rdnpart;
>       }
>       $dn .= $rdn;
>     }
>     else                # single part RDN
>     {
>       return  if (!$part);
> 
>       $dn .= $part;
>     }
>   }
> 
>   return($dn);
> }
> 
> 
> These two basic functions now allow to implement 
> canonical_dn() with only a few lines:
> 
> sub canonical_dn($;$) {
>   my ($dn, $rev) = @_;
> 
>   $dn = $dn->dn if ref($dn);
> 
>   my @dnparts = splitDN($dn, uppercase => 1, splitRDN => 1, sortRDN => 1);
> 
>   joinDN(@dnparts, reversed => ($rev||0));
> }
> 
> 
> 
> 
> Yours
> Peter
> 
> -- 
> Peter Marschall     |   eMail: pet...@ma...
> Scheffelstraße 15   |          pet...@is...
> 97072 Würzburg      |   Tel:   0931/14721
> PGP:  D7 FF 20 FE E6 6B 31 74  D1 10 88 E0 3C FE 28 35
> 

Re: schema format questions

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

On Sun, Jan 06, 2002 at 09:00:28PM +0100, Peter Marschall wrote:
> Hi,
> 
> I have two questions about the frmat of schema entries that
> may be a little off topic, but bay also affect perl-ldap:
> 
> * Is ' (single quote) legal inside qdstrings in schema definitions 
>   RFC2252 does not explicitely deny it. It simply gives the
>   following definitions
> 
>       dstring         = 1*utf8
>       qdstring        = whsp "'" dstring "'" whsp
> 
>   without defining utf8 further
>   Since a single quote is a utf8 character, this could mean
>   that single quotes inside qdstrings are really allowed.
>   So
>       DESC 'New Object's FS Rights'
>   might be a legal description.

An interesting question. It would make parsing rather interesting. You are right
that the RFC does not disallow this. Net::LDAP assumed that no sensible person
would do that (like many apps assume no sensible person puts spacing in filenames :)

If you can provide a schema (or subset of one) with this I will see what I can do.

> * Is _ (underscore) a legal character in private extensions to
>   schema elements ?
>    RFC2252 does not explicitely forbid it.
>    It simply says:
>        "Terms which begin with the characters "X-" are reserved
>        for private experiments, and MUST be followed by a
>         <qdstrings>"
>    But no correlation is made between the word term and
>    any formally defined word.
>    So
>       X-NDS_NOT_SCHED_SYNC_IMMEDIATE '1'
>    might be a legal extension.

Yes, I think that is OK. Again an example will be most useful.

> I do not ask this just for fun.
> I find the assumptions made by Net::LDAP::Schema reasonable
> (since the things above make parsing the schema quite hard).

Right. Its not so much that it is hard, but it will be slower.

> But I have a directory server (guess which manufacturer ;-))

I don't need to :)

> that contains those elements in the schema, making the schema
> un-parseable by Net::LDAP::Schema.
> 
> Before I go out and tell them to correct their schema description
> accordng to RFC I would like to get ohers' opinions if such a schema
> conforms to RFC2252.
> 
> Last but not least, I have a very rough patch available that would allow
> to parse such a schema. But I have to polish it  a bitbefore I send it.
> Are you interested ?

Sure. Don't spend too much time polishing it before letting others test it.
Just a correct patch is fine, it can be polished later.

Graham.

Search Filter Problem - Can't Search on cn or givenName

[Philip L. <pl...@ar...>]

All:

Someone was kind enough to show me how to debug this.

I inserted a print "$query\n" after the search set up and got back 39 lines
before it choked (there are over 1000 lines in the file). The line it choked
on had a "comment" in the first name field consisting of the user's business
group name surrounded by parens. Once I removed these comments from the 5
records that had them the script ran fine.

Just another unexciting instance of G-I-G-O.

Thanks for everyone's help on this.


Phil

Proposed Schema.pm

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

Attached is a proposed Schema.pm. It is far simpler internally than the
previous one. Basically the methods that now exist are

all_attributes
all_objectclasses
all_syntaxes
all_matchingrules
all_matchingruleuses
all_ditstructurerules
all_ditcontentrules
all_nameforms

  Returns the elements for the requested type.

attribute
objectclass
syntax
matchingrule
matchingruleuse
ditstructurerule
ditcontentrule
nameform

  Takes a list of names/OIDs and returns the elements if
  they are of the requested type.

  Q: Should these accept a list or just one argument ?

must
may

  Takes a list of objectclass names/OIDs and returns the attribute
  elements that an entry of that type must/may have

attribute_syntax

  Given an attribute name/OID returns the syntax element for
  the attribute.

An element is a hash reference (could be made to be an object)

Comments ?

Graham.

RE: Search Filter Problem - Can't Search on cn or givenName

[Philip L. <pl...@ar...>]

Chris:

Thanks for the quick reply. I made the changes suggested, but it still
doesn't seem to be working. My return code is "255" with the text message,
"Failed to search with Bad filter". No results are returned, so it looks
like it's failing immediately. Are there some things I should be checking on
the server (other than the indexing, although can I really be sure that the
indexes are really "working"?)?

Phil


-----Original Message-----
From: Chris Ridd [mailto:chr...@me...]
Sent: Tuesday, January 08, 2002 5:33 AM
To: Philip Lembo; per...@li...
Subject: Re: Search Filter Problem - Can't Search on cn or givenName


Philip Lembo <pl...@ar...> wrote:
> I hope you'll all excuse what's probably a really basic error on my part,
> but I'm having trouble with any search filter that includes givenName or
> commonName as a term. Both these attribs are indexed sub, eq and pres.
> We're using Netscape Directory 4.12 here.
>
> My script loops through a .csv file which includes the First and Last Name
> of a user on each line. What I'm trying to do is match against either
> First AND Last Name or Full Name (cn) on the Directory. It does work if I
> only include the Last Name (although the result of such a search is
> pretty much useless for my purposes).
>
> Here's my code (excuse the poor programming style, Until a year ago I was
> just an NT desktop guy -- better to be embaressed than to continue in
> ignorance though):
>
> use strict;
> use Net::LDAP;
> use Text::ParseWords;
>
> # Global variables for bind
> my $host = 'ldap.arrow.com';
> my $ldap = new Net::LDAP($host);
> my $mesg = $ldap->bind('cn=Directory Manager', password=> 'xxxxxxx');
> die ("failed to bind with ",$mesg->code(),"\n") if $mesg->code();
>
> # Open the data files
> open INFILE, '<users.csv' or die $!;
> open OUTFILE, '>users-uid.csv' or die $!;
>
> # Print a header in the outfile
> print OUTFILE "LanId,LName,FName,Guid,Email\n";
>
> # Parse infile, format: LanId, LName, FName
> while (<INFILE>) {
> 	chomp;
> 	my ($LanId,
> 	    $LName,
> 	    $FName
> 	)
> 		= ( &parse_line(',',0,$_));
>
> my $CName = "$FName $LName";
>
> # Set up search variables
> 	my $attrs = "uid,sn,givenname,mail,cn";

Ah, that should be:

	my $attrs = ["uid", "sn", "givenname", "mail", "cn"]

because the attr argument to search takes a reference to a list as the
parameter. (Which is what the [ and ] construct.)

As it stands, you're asking the server to return a single attribute called
"uid,sn,givenname,mail,cn", which probably won't exist.

What result code is returned from the searches, and how many results come
back from each one?

Cheers,

Chris

Re: Search Filter Problem - Can't Search on cn or givenName

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

Philip Lembo <pl...@ar...> wrote:
> I hope you'll all excuse what's probably a really basic error on my part,
> but I'm having trouble with any search filter that includes givenName or
> commonName as a term. Both these attribs are indexed sub, eq and pres.
> We're using Netscape Directory 4.12 here.
> 
> My script loops through a .csv file which includes the First and Last Name
> of a user on each line. What I'm trying to do is match against either
> First AND Last Name or Full Name (cn) on the Directory. It does work if I
> only include the Last Name (although the result of such a search is
> pretty much useless for my purposes).
> 
> Here's my code (excuse the poor programming style, Until a year ago I was
> just an NT desktop guy -- better to be embaressed than to continue in
> ignorance though):
> 
> use strict;
> use Net::LDAP;
> use Text::ParseWords;
> 
> # Global variables for bind
> my $host = 'ldap.arrow.com';
> my $ldap = new Net::LDAP($host);
> my $mesg = $ldap->bind('cn=Directory Manager', password=> 'xxxxxxx');
> die ("failed to bind with ",$mesg->code(),"\n") if $mesg->code();
> 
> # Open the data files
> open INFILE, '<users.csv' or die $!;
> open OUTFILE, '>users-uid.csv' or die $!;
> 
> # Print a header in the outfile
> print OUTFILE "LanId,LName,FName,Guid,Email\n";
> 
> # Parse infile, format: LanId, LName, FName
> while (<INFILE>) {
> 	chomp;
> 	my ($LanId,
> 	    $LName,
> 	    $FName
> 	)
> 		= ( &parse_line(',',0,$_));
> 
> my $CName = "$FName $LName";
> 
> # Set up search variables
> 	my $attrs = "uid,sn,givenname,mail,cn";

Ah, that should be:

	my $attrs = ["uid", "sn", "givenname", "mail", "cn"]

because the attr argument to search takes a reference to a list as the
parameter. (Which is what the [ and ] construct.)

As it stands, you're asking the server to return a single attribute called
"uid,sn,givenname,mail,cn", which probably won't exist.

What result code is returned from the searches, and how many results come
back from each one?

Cheers,

Chris

Re: Suggested Schema changes

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

Graham Barr <gb...@po...> wrote:
> On Mon, Jan 07, 2002 at 02:36:34PM +0000, Graham Barr wrote:
>> I think the root of the problems with Schema.pm is that ->item is used as
>> an accessor for all types, and the the internal structures are wrong.
>> Also The methods return names or OIDs, which them must be passed to item
>> to retrieve.
>> 
>> Here is what I propose
>> 
>> Internals
>> 
>>   $schema = {
>>     # OID will be a hashref mapping the OID (number or un-altered name)
>>     to the hash # which holds the elements data
>>     oid => { ... },
>> 
>>     # at will be a hash mapping the lower case version of the names and
>>     aliases # of attributes to the hash for the element
>>     at  => { ... },
>> 
>>     # Same as at for all other types
>>     etc..
>>   };
>> 
>> The API then needs to change.
>> 
>> We do away with ->item and make is_attribute return the element hash.
>> This way we know that the given name/OID should be an attribute or
>> syntaxrule or whatever. If we really want to hide the contents of the
>> element hash, then we should just bless it into another package which
>> contains accessor methods.
>> 
>> So now instead of
>> 
>>   $href = $schema->item('userName');
>>   $syn  = $schema->item('userName','syntax');
>> 
>> you will do
>> 
>>   $href = $schema->is_attribute('userName');
>>   $syn  = $schema->is_attribute('userName')->{syntax};
>> 
>> However, I dont really like the is_ prefix on these methods, but
>> dropping that makes the name too close to existing methods (attributes)
>> which return all attributes, so if anyone has any ideas (or they do not
>> think it will be a problem), then fire away.
> 
> In fact it seems that what I was trying to describe is similar to the
> Java API.
> 
> For those not familiar with it, see
> 
> http://docs.iplanet.com/docs/manuals/dirsdk/jsdk41/Reference/index.html
> 
> And look at the LDAPSchema and LDAPSchemaElement class definitions.

Yes, that sounds about right. I'm slightly unhappy with the methods being
called 'is_*' given this usage:

$schema->is_attribute('userName')->{syntax};

I prefer the Netscape method naming style, although it does mean that there
will be different methods with very similar names ('getAttribute' returning
a single definition and 'etAttributes' returning an enumeration).

How about 'attribute' for the single definition, and 'all_attributes' for,
well, all of them?

Cheers,

Chris

Search Filter Problem - Can't Search on cn or givenName

[Philip L. <pl...@ar...>]

I hope you'll all excuse what's probably a really basic error on my part,
but I'm having trouble with any search filter that includes givenName or
commonName as a term. Both these attribs are indexed sub, eq and pres. We're
using Netscape Directory 4.12 here.

My script loops through a .csv file which includes the First and Last Name
of a user on each line. What I'm trying to do is match against either First
AND Last Name or Full Name (cn) on the Directory. It does work if I only
include the Last Name (although the result of such a search is pretty much
useless for my purposes).

Here's my code (excuse the poor programming style, Until a year ago I was
just an NT desktop guy -- better to be embaressed than to continue in
ignorance though):

use strict;
use Net::LDAP;
use Text::ParseWords;

# Global variables for bind
my $host = 'ldap.arrow.com';
my $ldap = new Net::LDAP($host);
my $mesg = $ldap->bind('cn=Directory Manager', password=> 'xxxxxxx');
die ("failed to bind with ",$mesg->code(),"\n") if $mesg->code();

# Open the data files
open INFILE, '<users.csv' or die $!;
open OUTFILE, '>users-uid.csv' or die $!;

# Print a header in the outfile
print OUTFILE "LanId,LName,FName,Guid,Email\n";

# Parse infile, format: LanId, LName, FName
while (<INFILE>) {
	chomp;
	my ($LanId,
	    $LName,
	    $FName
	)
		= ( &parse_line(',',0,$_));

my $CName = "$FName $LName";

# Set up search variables
	my $attrs = "uid,sn,givenname,mail,cn";
	my $basedn = "o=company";
	my $query = "(cn=$CName)";

	# Or this which also doesn't work
	# my $query = "(&(sn=$LName)(givenname=$FName))";

	$mesg = $ldap->search(	base => $basedn,
				scope => 'sub',
				filter => $query,
				attr => $attrs
		);
	die "Failed to search with ",$mesg->error(),"\n" if $mesg->code();

	# Get values from LDAP
	while (my $entry = $mesg->shift_entry()) {
	   my $Guid = $entry->get_value('uid');
	   my $Email = $entry->get_value('mail');

	# Print results to  file
	   print OUTFILE "$LanId";
	   print OUTFILE ",";
	   print OUTFILE "\"$LName\"";
	   print OUTFILE ",";
	   print OUTFILE "\"$FName\"";
	   print OUTFILE ",";
	   print OUTFILE "$Guid";
	   print OUTFILE ",";
	   print OUTFILE "$Email";
	   print OUTFILE "\n";

	}

}
$ldap->unbind();

close INFILE;
close OUTFILE;

__END__;



--
PHILIP LEMBO
Systems Engineer
Arrow Electronics, Inc.
e-mail: pl...@ar...
voice:  631 847 5355

Re: Suggested Schema changes

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

On Mon, Jan 07, 2002 at 02:36:34PM +0000, Graham Barr wrote:
> I think the root of the problems with Schema.pm is that ->item is used as
> an accessor for all types, and the the internal structures are wrong.
> Also The methods return names or OIDs, which them must be passed to item
> to retrieve.
> 
> Here is what I propose
> 
> Internals
> 
>   $schema = {
>     # OID will be a hashref mapping the OID (number or un-altered name) to the hash
>     # which holds the elements data
>     oid => { ... },
> 
>     # at will be a hash mapping the lower case version of the names and aliases
>     # of attributes to the hash for the element
>     at  => { ... },
> 
>     # Same as at for all other types
>     etc..
>   };
> 
> The API then needs to change.
> 
> We do away with ->item and make is_attribute return the element hash. This way we know
> that the given name/OID should be an attribute or syntaxrule or whatever. If we
> really want to hide the contents of the element hash, then we should just bless it
> into another package which contains accessor methods.
> 
> So now instead of
> 
>   $href = $schema->item('userName');
>   $syn  = $schema->item('userName','syntax');
> 
> you will do
> 
>   $href = $schema->is_attribute('userName');
>   $syn  = $schema->is_attribute('userName')->{syntax};
> 
> However, I dont really like the is_ prefix on these methods, but dropping that makes
> the name too close to existing methods (attributes) which return all attributes,
> so if anyone has any ideas (or they do not think it will be a problem), then fire away.

In fact it seems that what I was trying to describe is similar to the Java API.

For those not familiar with it, see

http://docs.iplanet.com/docs/manuals/dirsdk/jsdk41/Reference/index.html

And look at the LDAPSchema and LDAPSchemaElement class definitions.

Graham.

Suggested Schema changes

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

I think the root of the problems with Schema.pm is that ->item is used as
an accessor for all types, and the the internal structures are wrong.
Also The methods return names or OIDs, which them must be passed to item
to retrieve.

Here is what I propose

Internals

  $schema = {
    # OID will be a hashref mapping the OID (number or un-altered name) to the hash
    # which holds the elements data
    oid => { ... },

    # at will be a hash mapping the lower case version of the names and aliases
    # of attributes to the hash for the element
    at  => { ... },

    # Same as at for all other types
    etc..
  };

The API then needs to change.

We do away with ->item and make is_attribute return the element hash. This way we know
that the given name/OID should be an attribute or syntaxrule or whatever. If we
really want to hide the contents of the element hash, then we should just bless it
into another package which contains accessor methods.

So now instead of

  $href = $schema->item('userName');
  $syn  = $schema->item('userName','syntax');

you will do

  $href = $schema->is_attribute('userName');
  $syn  = $schema->is_attribute('userName')->{syntax};

However, I dont really like the is_ prefix on these methods, but dropping that makes
the name too close to existing methods (attributes) which return all attributes,
so if anyone has any ideas (or they do not think it will be a problem), then fire away.

Graham.

Re: Reguested Schema data

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

Chris,

I sent Graham a new Schema.pm file last Friday night that addresses
the problems I was seeing with missing data and the 
attribute/objectclass naming situation.

Graham is reviewing my changes.

Later,

Clif


> 
> Graham Barr <gb...@po...> wrote:
> > On Thu, Jan 03, 2002 at 09:50:04PM -0600, Clif Harden wrote:
> >> Graham,  
> >> 
> >> I have attached 2 files that contain data about the schema 
> >> problem.  
> >> 
> >> ldap.oids.gz contains oids that do not return data.  
> >> 
> >> ldap.schema.gz is a complete schema from one of my test 
> >> netscape directory servers.  
> > 
> > Thanks.
> > 
> >> If possible, possibly now or in the future, I would like to 
> >> see us do away with changing the case of the oids and names. 
> >> I have not had a chance to see how hard this would be.  
> > 
> > You cannot. Attribute names etc are not case sensetive. So the module
> > must ignore case when doing a lookup for the name supplied.
> > 
> > Graham.
> 
> Correct, however Clif also adds:
> 
> >> away with creating multi-valued oid strings.  On one of my servers I
> >> have an objectclass named mhsMessagingStore and an attribute aliased as
> >> MHSMessagingStore, when we lower case the names and aliases in this case
> >> we create the same name pointing to 2 different
> >> oids.
> 
> This means that we need multiple oid 'namespaces', as Clif has two OIDs -
> one an objectclass and one an attribute - with the same name.
> 
> We currently have a single %oid object per Schema object, so we could do
> something like prefix each oid string with "at" or "oc". I'm not sure if
> that's the best solution, or if this would cause other problems. (For
> example, what would you do with values for an attribute that has an OID
> syntax - would the values be 'at' or 'oc' OIDs?)
> 
> Cheers,
> 
> Chris
> 
> 

Re: Reguested Schema data

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

On Mon, Jan 07, 2002 at 12:53:42PM -0000, Chris Ridd wrote:
> > You cannot. Attribute names etc are not case sensetive. So the module
> > must ignore case when doing a lookup for the name supplied.
> > 
> > Graham.
> 
> Correct, however Clif also adds:
> 
> >> away with creating multi-valued oid strings.  On one of my servers I
> >> have an objectclass named mhsMessagingStore and an attribute aliased as
> >> MHSMessagingStore, when we lower case the names and aliases in this case
> >> we create the same name pointing to 2 different
> >> oids.
> 
> This means that we need multiple oid 'namespaces', as Clif has two OIDs -
> one an objectclass and one an attribute - with the same name.
> 
> We currently have a single %oid object per Schema object, so we could do
> something like prefix each oid string with "at" or "oc". I'm not sure if
> that's the best solution, or if this would cause other problems. (For
> example, what would you do with values for an attribute that has an OID
> syntax - would the values be 'at' or 'oc' OIDs?)

This is inline whith what I have been thinking. Not doing the lc() is not the solution.

Internally we need to split %oid into several say $oid{at}{$oid}

That would also allow us to get all attributes easily, which we currently do
differently.

We then need to look at the API. Currently we do $schema->item($what), I think
the API needs a way to specifiy, get data from this attribute etc. as well as
the general get me this.

I have a few ideas in my head. I will see if I can put something together.

Graham.

Re: Reguested Schema data

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

Graham Barr <gb...@po...> wrote:
> On Thu, Jan 03, 2002 at 09:50:04PM -0600, Clif Harden wrote:
>> Graham,  
>> 
>> I have attached 2 files that contain data about the schema 
>> problem.  
>> 
>> ldap.oids.gz contains oids that do not return data.  
>> 
>> ldap.schema.gz is a complete schema from one of my test 
>> netscape directory servers.  
> 
> Thanks.
> 
>> If possible, possibly now or in the future, I would like to 
>> see us do away with changing the case of the oids and names. 
>> I have not had a chance to see how hard this would be.  
> 
> You cannot. Attribute names etc are not case sensetive. So the module
> must ignore case when doing a lookup for the name supplied.
> 
> Graham.

Correct, however Clif also adds:

>> away with creating multi-valued oid strings.  On one of my servers I
>> have an objectclass named mhsMessagingStore and an attribute aliased as
>> MHSMessagingStore, when we lower case the names and aliases in this case
>> we create the same name pointing to 2 different
>> oids.

This means that we need multiple oid 'namespaces', as Clif has two OIDs -
one an objectclass and one an attribute - with the same name.

We currently have a single %oid object per Schema object, so we could do
something like prefix each oid string with "at" or "oc". I'm not sure if
that's the best solution, or if this would cause other problems. (For
example, what would you do with values for an attribute that has an OID
syntax - would the values be 'at' or 'oc' OIDs?)

Cheers,

Chris

schema format questions

[Peter M. <pet...@ma...>]

Hi,

I have two questions about the frmat of schema entries that
may be a little off topic, but bay also affect perl-ldap:

* Is ' (single quote) legal inside qdstrings in schema definitions=20
  RFC2252 does not explicitely deny it. It simply gives the
  following definitions

      dstring         =3D 1*utf8
      qdstring        =3D whsp "'" dstring "'" whsp

  without defining utf8 further
  Since a single quote is a utf8 character, this could mean
  that single quotes inside qdstrings are really allowed.
  So
      DESC 'New Object's FS Rights'
  might be a legal description.
* Is _ (underscore) a legal character in private extensions to
  schema elements ?
   RFC2252 does not explicitely forbid it.
   It simply says:
       "Terms which begin with the characters "X-" are reserved
       for private experiments, and MUST be followed by a
        <qdstrings>"
   But no correlation is made between the word term and
   any formally defined word.
   So
      X-NDS_NOT_SCHED_SYNC_IMMEDIATE '1'
   might be a legal extension.

I do not ask this just for fun.
I find the assumptions made by Net::LDAP::Schema reasonable
(since the things above make parsing the schema quite hard).

But I have a directory server (guess which manufacturer ;-))
that contains those elements in the schema, making the schema
un-parseable by Net::LDAP::Schema.

Before I go out and tell them to correct their schema description
accordng to RFC I would like to get ohers' opinions if such a schema
conforms to RFC2252.

Last but not least, I have a very rough patch available that would allow
to parse such a schema. But I have to polish it  a bitbefore I send it.
Are you interested ?

Yours
Peter

--=20
Peter Marschall     |   eMail: pet...@ma...
Scheffelstra=DFe 15   |          pet...@is...
97072 W=FCrzburg      |   Tel:   0931/14721
PGP:  D7 FF 20 FE E6 6B 31 74  D1 10 88 E0 3C FE 28 35

Re: canonical_dn

[Peter M. <pet...@ma...>]

Sorry,=20

a few small errors in my last mail's listings.
Here's the corrected version

Yours
Peter

----------  Forwarded Message  ----------

Subject: canonical_dn
Date: Sun, 6 Jan 2002 13:45:17 +0100
From: Peter Marschall <pet...@ma...>
To: per...@li...

Hi,

i have tried to use canonical_dn with UTF 8 and I think
it treats strings with UTF8 encoded values wrong.
Characters with codes > 127 have UTF8 encodings that
consist of 2 or more bytes that have all codes > 127.
Since these characters are legal in LDAPv3 DNs they should
not get escaped.
So line 310 of Net/LDAP/Util.pm should read

  $val =3D~ s/([\x00-\x1f])/sprintf("\\%02x",ord($1))/eg;

instead of the current version:

    $val =3D~ s/([\x00-\x1f\x7f-\xff])/sprintf("\\%02x",ord($1))/eg;


When changing canonical_dn() anyway, maybe changing the
implementation into three functions would be helpful.
It would give users of Net::LDAP a standardized way of dealing with
DNs and parts of it (very helpful when moving entries, ..) without having
to reimplement the wheel themselves.

Here is my idea:


## split a DN string into its parts; code stolen from canonical_dn() ##
# Synopsis:  @rdns =3D splitDN($dn, %optionHash)
# allowed options:
#  * lowercase: convert attribute names to lower case
#  * uppercase: convert attribute names to upper case
#  * sortRDN: sort RDN values
#  * splitRDN: split multi part RDNs into their parts
sub splitDN($%)
{
my $dn =3D shift;
my %opt =3D @_;
my @dn;
my @rdn;

 $dn =3D $dn->dn if ref($dn);

  while ($dn =3D~ /\G(?:
                \s*
                ([a-zA-Z][-a-zA-Z0-9]*|(?:[Oo][Ii][Dd]\.)?\d+(?:\.\d+)*)
                \s*
                =3D
                \s*
                (
                  (?:[^\\",=3D+<>\#;]*[^\\",=3D+<>\#;\s]|\\(?:[\\
",=3D+<>#;]|[0-9a-fA-F]{2}))*

                  \#(?:[0-9a-fA-F]{2})+

                  "(?:[^\\"]+|\\(?:[\\",=3D+<>#;]|[0-9a-fA-F]{2}))*"
                )
                \s*
                (?:([;,+])\s*(?=3D\S)|$)
                )\s*/gcx)
  {
  my ($type,$val,$sep) =3D ($1,$2,$3);

    $type =3D~ s/^oid\.(\d+(\.\d+)*)$/$1/i;
    $type =3D lc($type)  if ($opt{lowercase});
    $type =3D uc($type)  if ($opt{uppercase});

    if ($val !~ /^#/)
    {
      $val =3D~ s/^"(.*)"$/$1/;
      $val =3D~ s/\\([\\ ",=3D+<>#;]|[0-9a-fA-F]{2})
               /length($1)=3D=3D1 ? $1 : chr(hex($1))
               /xeg;
      $val =3D~ s/([\\",=3D+<>#;])/\\$1/g;
      $val =3D~ s/([\x00-\x1F])/sprintf("\\%02x",ord($1))/eg;

      $val =3D~ s/(^\s+|\s+$)/"\\20" x length $1/ge;
    }

    push @rdn, "$type=3D$val";

    unless (defined $sep and $sep eq '+')
    {
      @rdn =3D sort(@rdn)  if ($opt{sortRDN});
      push @dn, ($opt{splitRDN}) ?
                  ((scalar(@rdn) > 1) ? [ @rdn ] : ($rdn[0] || '')) :
                  join('+', @rdn);
      @rdn =3D ();
    }
  }

  return((length($dn) !=3D (pos($dn) || 0)) ? () : @dn);
}


## join RDNs and RDN parts into a DN string ##
# Synopsis:  $dn =3D joinDN(@dnpartref, %optionhash)
sub joinDN(\@%)
{
my @dnparts =3D @i{+shift};
my %opt =3D @_;
my $dn =3D '';

  @dnparts =3D reverse(@dnparts)  if ($opt{reversed});

  foreach my $part (@dnparts)
  {
    $dn .=3D (($opt{reversed}) ? '\000' : ',')  if ($dn);

    if (ref($part))     # multi part RDN
    {
    my $rdn;

      foreach my $rdnpart (@$part)
      {
        return  if (!$rdnpart);

        $rdn .=3D (($opt{reversed}) ? '\001' : '+')  if ($rdn);
        $rdn .=3D $rdnpart;
      }
      $dn .=3D $rdn;
    }
    else                # single part RDN
    {
      return  if (!$part);

      $dn .=3D $part;
    }
  }

  return($dn);
}


These two basic functions now allow to implement
canonical_dn() with only a few lines:

sub canonical_dn($;$) {
  my ($dn, $rev) =3D @_;

  $dn =3D $dn->dn if ref($dn);

  my @dnparts =3D splitDN($dn, uppercase =3D> 1, splitRDN =3D> 1, sortRDN=
 =3D> 1);

  joinDN(@dnparts, reversed =3D> ($rev||0));
}




Yours
Peter

--
Peter Marschall     |   eMail: pet...@ma...
Scheffelstra=DFe 15   |          pet...@is...
97072 W=FCrzburg      |   Tel:   0931/14721
PGP:  D7 FF 20 FE E6 6B 31 74  D1 10 88 E0 3C FE 28 35

-------------------------------------------------------

--=20
Peter Marschall     |   eMail: pet...@ma...
Scheffelstra=DFe 15   |          pet...@is...
97072 W=FCrzburg      |   Tel:   0931/14721
PGP:  D7 FF 20 FE E6 6B 31 74  D1 10 88 E0 3C FE 28 35

canonical_dn

[Peter M. <pet...@ma...>]

Hi,

i have tried to use canonical_dn with UTF 8 and I think
it treats strings with UTF8 encoded values wrong.
Characters with codes > 127 have UTF8 encodings that
consist of 2 or more bytes that have all codes > 127.
Since these characters are legal in LDAPv3 DNs they should
not get escaped.
So line 310 of Net/LDAP/Util.pm should read

  $val =3D~ s/([\x00-\x1f])/sprintf("\\%02x",ord($1))/eg;

instead of the current version:

    $val =3D~ s/([\x00-\x1f\x7f-\xff])/sprintf("\\%02x",ord($1))/eg;


When changing canonical_dn() anyway, maybe changing the=20
implementation into three functions would be helpful.
It would give users of Net::LDAP a standardized way of dealing with=20
DNs and parts of it (very helpful when moving entries, ..) without having
to reimplement the wheel themselves.

Here is my idea:


## split a DN string into its parts; code stolen from canonical_dn() ##
# Synopsis:  @rdns =3D splitDN($dn, %optionHash)
# allowed options:
#  * lowercase: convert attribute names to lower case
#  * uppercase: convert attribute names to upper case
#  * sortRDN: sort RDN values
#  * splitRDN: split multi part RDNs into their parts
sub splitDN($%)
{
my $dn =3D shift;
my %opt =3D @_;
my @dn;
my @rdn;

 $dn =3D $dn->dn if ref($dn);

  while ($dn =3D~ /\G(?:
                \s*
                ([a-zA-Z][-a-zA-Z0-9]*|(?:[Oo][Ii][Dd]\.)?\d+(?:\.\d+)*)
                \s*
                =3D
                \s*
                (
                  (?:[^\\",=3D+<>\#;]*[^\\",=3D+<>\#;\s]|\\(?:[\\=20
",=3D+<>#;]|[0-9a-fA-F]{2}))*
                  |
                  \#(?:[0-9a-fA-F]{2})+
                  |
                  "(?:[^\\"]+|\\(?:[\\",=3D+<>#;]|[0-9a-fA-F]{2}))*"
                )
                \s*
                (?:([;,+])\s*(?=3D\S)|$)
                )\s*/gcx)
  {
  my ($type,$val,$sep) =3D ($1,$2,$3);

    $type =3D~ s/^oid\.(\d+(\.\d+)*)$/$1/i;
    $type =3D lc($type)  if ($opt{lowercase});
    $type =3D uc($type)  if ($opt{uppercase});

    if ($val !~ /^#/)
    {
      $val =3D~ s/^"(.*)"$/$1/;
      $val =3D~ s/\\([\\ ",=3D+<>#;]|[0-9a-fA-F]{2})
               /length($1)=3D=3D1 ? $1 : chr(hex($1))
               /xeg;
      $val =3D~ s/([\\",=3D+<>#;])/\\$1/g;
      $val =3D~ s/([\x00-\x1F])/sprintf("\\%02x",ord($1))/eg;

      $val =3D~ s/(^\s+|\s+$)/"\\20" x length $1/ge;
    }

    push @rdn, "$type=3D$val";

    unless (defined $sep and $sep eq '+')
    {
      @rdn =3D sort(@rdn)  if ($opt{sortRDN});
      push @dn, ($opt{splitRDN}) ?
                  ((scalar(@rdn) > 1) ? [ @rdn ] : ($rdn[0] || '')) :
                  join('+', @rdn);
      @rdn =3D ();
    }
  }

  return((length($dn) !=3D (pos($dn) || 0)) ? () : @dn);
}


## join RDNs and RDN parts into a DN string ##
# Synopsis:  $dn =3D joinDN(@dnpartref, %optionhash)
sub joinDN(\@%)
{
my @dnparts =3D @i{+shift};
my %opt =3D @_;
my $dn =3D '';

  @dnparts =3D reverse(@dnparts)  if ($opt{reversed});

  foreach my $part (@dnparts)
  {
    $dn .=3D (($opt{reversed}) ? \000 : ',')  if ($dn);

    if (ref($part))     # multi part RDN
    {
    my $partlist =3D ($opt{revered}) ? reverse(@$part) : @$part;
    my $rdn;

      foreach my $rdnpart (@partlist)
      {
        return  if (!$rdnpart);

        $rdn .=3D (($opt{reversed}) ? \001 : '+')  if ($rdn);
        $rdn .=3D $rdnpart;
      }
      $dn .=3D $rdn;
    }
    else                # single part RDN
    {
      return  if (!$part);

      $dn .=3D $part;
    }
  }

  return($dn);
}


These two basic functions now allow to implement=20
canonical_dn() with only a few lines:

sub canonical_dn($;$) {
  my ($dn, $rev) =3D @_;

  $dn =3D $dn->dn if ref($dn);

  my @dnparts =3D splitDN($dn, uppercase =3D> 1, splitRDN =3D> 1, sortRDN=
 =3D> 1);

  joinDN(@dnparts, reversed =3D> ($rev||0));
}




Yours
Peter

--=20
Peter Marschall     |   eMail: pet...@ma...
Scheffelstra=DFe 15   |          pet...@is...
97072 W=FCrzburg      |   Tel:   0931/14721
PGP:  D7 FF 20 FE E6 6B 31 74  D1 10 88 E0 3C FE 28 35

Problem with Net::LDAP::Entry->get_value( "type", alloptions=>1 )

[Torsten <tor...@gm...>]

Hi

If an entry has 2 attributes named for example "klaus" and "klausotto" and 
you call Net::LDAP::Entry->get_value( "klaus", alloptions=>1 ) the returned 
hash contains the attribute values of klaus AND klausotto:

LDIF:
dn:...
klaus: klaus
klausotto: otto
klaus;en-us: blah

get_value( "klaus", alloptions=>1 ) returns:

{
  '' => 'klaus',
  'otto' => 'otto',
  ';en-us' => 'blah'
}

Changing line 81 of Entry.pm
from
    $_->{type} =~ /^\Q$type\E(.*)/ ? (lc($1), $_->{vals}) :()
to
    $_->{type} =~ /^\Q$type\E(;.*)?/ ? (lc($1||''), $_->{vals}) :()
fixes the problem.

Re: Reguested Schema data

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

On Thu, Jan 03, 2002 at 09:50:04PM -0600, Clif Harden wrote:
> Graham,  
> 
> I have attached 2 files that contain data about the schema 
> problem.  
> 
> ldap.oids.gz contains oids that do not return data.  
> 
> ldap.schema.gz is a complete schema from one of my test 
> netscape directory servers.  

Thanks.

> If possible, possibly now or in the future, I would like to 
> see us do away with changing the case of the oids and names. 
> I have not had a chance to see how hard this would be.  

You cannot. Attribute names etc are not case sensetive. So the module
must ignore case when doing a lookup for the name supplied.

Graham.

> 
> This would do away with some confusion and I know in my case would do
> away with creating multi-valued oid strings.  On one of my servers I
> have an objectclass named mhsMessagingStore and an attribute aliased as
> MHSMessagingStore, when we lower case the names and aliases in this case
> we create the same name pointing to 2 different
> oids.                                                                                 
> 
> I might be able to look into this problem some this weekend.
> 
> Regards,
> 
> Clif Harden          ch...@po...