Menu
▾
▴
perl-ldap-dev
|
From: Norbert K. <nor...@da...> - 2002-04-23 09:33:47
|
--On Freitag, 19. April 2002 08:43 +0100 Graham Barr <gb...@po...>
wrote:
> Whats wrong with the subs in Net::LDAP::Utils ?
ldap_explode_dn does not unescape escaped characters, e.g. the DN 'CN=3D\=
#John
Smith\ ' becomes
$VAR1 =3D {
'CN' =3D> '\\#John Smith\\20'
};
instad of
$VAR1 =3D {
'CN' =3D> '#John Smith '
};
likewise 'CN=3DLu\C4\8Di\C4\87' becomes
$VAR1 =3D {
'CN' =3D> 'Lu\\c4\\8di\\c4\\87'
};
instead of
$VAR1 =3D {
'CN' =3D> 'Lucic'
};
We needed the unescaped variants to display DNs nicely in our webgateway.
They are also needed, if an "exploded DN" is to be converted back to a pl=
ain
string. This "folding" can be done by canonical_dn. It now also takes a
reference to an array as returned by ldap_explode_dn in addition to plain
strings. This way, "move upwards" buttons can be implemented easily by
taking slices of arrays returned by ldap_explode_dn.
Additionally the behavior of the two functions concerning casefolding,
escaping and RDN ordering can be controlled by parameters:
FUNCTIONS
canonical_dn ( DN [ , OPTIONS ] )
Returns the given DN in a canonical form. Returns
undef if DN is not a valid Distinguished Name. (Note:
The empty string "" is a valid DN.) DN can either be
a string or a reference to an array of hashes as returned by
ldap_explode_dn.
It performs the following operations on the given DN:
o Removes the leading 'OID.' characters if the type
is an OID instead of a name.
o Escapes all RFC 2253 special characters (",", "+",
""", "\", "<", ">", ";", "#", "=3D", " "), slashes
("/"), and any other character where the ASCII
code is <32 as \hexpair.
o Converts all leading and trailing spaces in values
to be \20.
o If an RDN contains multiple parts, the parts are
re-ordered so that the attribute type names are in
alphabetical order.
OPTIONS is a list of name/value pairs, valid options
are:
binary
This argument is a reference to a list of
attribute type names . Values of these attribute
types will be escaped as #(hexpair)*.
casefold
Controls case folding of attribute type names.
Attribute values are not affected by this option.
The default is to uppercase. Valid values are:
lower
Lowercase attribute type names.
upper
Uppercase attribute type names. This is the
default.
none
Do not change attribute type names.
mbcescape
If TRUE, multi byte characters will be escaped as
\(hexpair){2,*}
reverse
If TRUE, the RDN sequence is reversed.
separator
Separator to use between RDNs. Defaults to comma
(',').
ldap_explode_dn ( DN [ , OPTIONS ] )
Explodes the given DN into an array of hashes.
Returns undef if DN is not a valid Distinguished Name.
It also performs the following operations on the given
DN:
o Unescape "\" followed by ",", "+", """, "\", "<",
">", ";", "#", "=3D", " ", or a hexpair and and
strings beginning with "#".
o Removes the leading OID. characters if the type is
an OID instead of a name.
OPTIONS is a list of name/value pairs, valid options
are:
casefold
Controls case folding of attribute types names.
Attribute values are not affected by this option.
The default is to uppercase. Valid values are:
lower
Lowercase attribute types names.
upper
Uppercase attribute type names. This is the
default.
none
Do not change attribute type names.
--
Norbert Klasen, Dipl.-Inform.
DAASI International GmbH phone: +49 7071 29 70336
Wilhelmstr. 106 fax: +49 7071 29 5114
72074 T=FCbingen email: nor...@da...
Germany web: http://www.daasi.de
|
|
From: Norbert K. <nor...@da...> - 2002-04-23 20:10:00
Attachments:
Util.patch.txt
|
--On Dienstag, 23. April 2002 15:59 +0100 Graham Barr <gb...@po...>=20 wrote: > But you code also expanded > > CN=3D\a0 to 'CN' =3D> chr(160) > > Which means in canonical_dn both end up as > > CN=3D\a0 > > which is wrong > > CN=3D\a0 is not the same as CN=3D#a0 > > The first is a value of 1 character length and its type, for comaprisons, > is the type of CN. The second is a value of unknown type and so cannot be > compared to the first. After rereading RFC2253 it seems to me that CN should not be used as an=20 examaple here since it is a type that has a string representation. One=20 could argue that CN=3D#xxxx is illegal altogether. > The #xxxxxx is normally a BER encodeing so to get the examples right > > CN=3D\01\01\42 is not the same as CN=3D#010142 nor is it the same > as CN=3D\42 > > So you need to make sure that DNs of CN=3D#.... get returned from > canonical_dn as #... and DN that don't start with # do not. > As long as we do not want to make canonical_dn schema aware, I think it=20 should be enough for canonical_dn to encode AttributeTypes of the=20 dotted-decimal form as #xxxx. Additional attriubte types can be specified=20 by the (renamed) ber parameter. One question that remains is whether and how ldap_explode_dn should mark=20 values exploded from #xxxx. (BTW do such things really occur in DNs?) I=20 would argue that there is no need for this: - Only AttributeValues which are of a type which does not have a string=20 representation defined for it are encoded as #xxxx. [RFC2253] - "clients MUST NOT assume that an unrecognized syntax is a string=20 representation" [RFC2252] So an application that supports attribute types without a string=20 representation will know how to handle their values and therefore needs no=20 extra help by perl-ldap. Attached patch to perl-ldap-0.25_01: - additional comments and documentation - renamed binary parameter in canonical_dn to ber - canonical_dn uses ldap_explode_dn reverse functionality - #xxxx encode dotted-decimal attribute types - don't use refs for #xxxx values - handling of empty DNs --=20 Norbert Klasen, Dipl.-Inform. DAASI International GmbH phone: +49 7071 29 70336 Wilhelmstr. 106 fax: +49 7071 29 5114 72074 T=FCbingen email: nor...@da... Germany web: http://www.daasi.de |
|
From: Graham B. <gb...@po...> - 2002-04-23 20:27:59
|
On Tue, Apr 23, 2002 at 10:07:09PM +0200, Norbert Klasen wrote:
> As long as we do not want to make canonical_dn schema aware, I think it
> should be enough for canonical_dn to encode AttributeTypes of the
> dotted-decimal form as #xxxx. Additional attriubte types can be specified
> by the (renamed) ber parameter.
>
> One question that remains is whether and how ldap_explode_dn should mark
> values exploded from #xxxx. (BTW do such things really occur in DNs?) I
> would argue that there is no need for this:
I did that by storing as a ref, but your patch seems to have removed it again.
I will be leaving that in there.
> - Only AttributeValues which are of a type which does not have a string
> representation defined for it are encoded as #xxxx. [RFC2253]
> - "clients MUST NOT assume that an unrecognized syntax is a string
> representation" [RFC2252]
> So an application that supports attribute types without a string
> representation will know how to handle their values and therefore needs no
> extra help by perl-ldap.
>
> Attached patch to perl-ldap-0.25_01:
> - additional comments and documentation
> - renamed binary parameter in canonical_dn to ber
> - canonical_dn uses ldap_explode_dn reverse functionality
> - #xxxx encode dotted-decimal attribute types
> - don't use refs for #xxxx values
Why ?
> - handling of empty DNs
>
> --- Util.pm-0.25_01 Tue Apr 23 20:35:04 2002
> +++ Util.pm Tue Apr 23 21:16:17 2002
> @@ -231,8 +231,8 @@
> sub canonical_dn($%) {
> - my $dn = shift or return '';
> + my $dn = shift;
> + return $dn unless $dn; # empty DN or undef
$dn = "0" ?
This should be return $dn unless $dn and length $dn;
> my %opt = @_;
>
> # create array of hash representation
> my @rdns;
> if ( ref $dn eq 'ARRAY' ) {
> - @rdns = @{$dn};
> + @rdns = $opt{reverse} ? reverse @{$dn} : @{$dn};
> } else {
> - @rdns = ldap_explode_dn( $dn ) or return undef; #error condition
> + @rdns = ldap_explode_dn( $dn, reverse => $opt{reverse} );
Does it really make sense for ldap_explode_dn todo the reverse ?
> - if ( ref($val) ) {
> - $val = '#' . unpack("H*", $$val);
> - }
I do not understand why you are taking this out ????
> - elsif ( $binary{lc $_} ) {
> - # escape binary attributes as #hexpair*
> + if ( $ber{lc $_} || $_ =~ /\d+(?:\.\d+)*/ ) {
This is wring, you cannot #xxx encode anything that was not
originally encoded that way. As such I dont see the point of the
ber parameter.
> + # escape unknown attribute types as #hexpair*
> $val = '#' . unpack("H*", $val);
> - #$val =~ s/(.)/sprintf("%02x",ord($1))/eg;
> - #$val = '#'.$val;
> } else {
> #escape insecure characters and optionally MBCs
> if ( $opt{mbcescape} ) {
> @@ -355,7 +356,7 @@
> "\\20" x length $1/xeg;
> }
>
> sub ldap_explode_dn($%) {
> - my $dn = shift or return;
> + my @emptydn = (); #empty DN array for scalar context
> + my $dn = shift;
> + return wantarray ? [] : \@emptydn if $dn eq '';
This does not make sense. You are returning a scalar ref
when wantarray is true. Did you mean
return wantarray ? () : [] if $dn eq '';
> my %opt = @_;
>
> my (@dn, %rdn);
> + $dn =~ s/^<(.*)>$/$1/; #remove brackets
why ? where is it defined that DNs have <> brackets ?
> while (
> $dn =~ /\G(?:
> \s*
> @@ -459,9 +481,9 @@
> }
>
> if ( $val =~ s/^#// ) {
> - # unescape hex sequence
> - (my $tmp = $val) =~ s/([0-9a-fA-F]{2})/chr(hex($1))/eg;
> - $val = \$tmp;
> + # unescape hex encoded BER value
> + $val = pack("H*", $val);
This is wrong, canonical_dn needs to know when to generate #xxx
and when not to. And you cannot depend on the attribute name
for that.
Graham.
|
|
From: Norbert K. <nor...@da...> - 2002-04-24 17:11:16
|
Hi Graham,
I put the #xxxx issue in a separate mail.
>> --- Util.pm-0.25_01 Tue Apr 23 20:35:04 2002
>> +++ Util.pm Tue Apr 23 21:16:17 2002
>> @@ -231,8 +231,8 @@
>
>> sub canonical_dn($%) {
>> - my $dn =3D shift or return '';
>> + my $dn =3D shift;
>> + return $dn unless $dn; # empty DN or undef
>
> $dn =3D "0" ?
This is another case to consider.
> This should be return $dn unless $dn and length $dn;
return $dn if $dn eq '' || !defined $dn ; # empty DN or undef
This handles undef, '' and "0" (leads to an error later).
>> my %opt =3D @_;
>>
>> # create array of hash representation
>> my @rdns;
>> if ( ref $dn eq 'ARRAY' ) {
>> - @rdns =3D @{$dn};
>> + @rdns =3D $opt{reverse} ? reverse @{$dn} : @{$dn};
>> } else {
>> - @rdns =3D ldap_explode_dn( $dn ) or return undef; #error condition
>> + @rdns =3D ldap_explode_dn( $dn, reverse =3D> $opt{reverse} );
>
> Does it really make sense for ldap_explode_dn todo the reverse ?
I added a reverse option to ldap_explode_dn and though it would be a good=20
idea to use it from canonical_dn as well. Am I missing something?
>> sub ldap_explode_dn($%) {
>> - my $dn =3D shift or return;
>> + my @emptydn =3D (); #empty DN array for scalar context
>> + my $dn =3D shift;
>> + return wantarray ? [] : \@emptydn if $dn eq '';
>
> This does not make sense. You are returning a scalar ref
> when wantarray is true. Did you mean
>
> return wantarray ? () : [] if $dn eq '';
I'm not that familar with these elements of Perl so it tell you what a I=20
actually had in mind: The return value of ldap_explode_dn should give the=20
user an indication, whether an invalid DN was passed in. The problem is now =
that the (valid) empty DN '' explodes to an empty array. In the scalar=20
context one can return undef or a reference to an empty array but I don't=20
know to express this in list context.
>> my %opt =3D @_;
>>
>> my (@dn, %rdn);
>> + $dn =3D~ s/^<(.*)>$/$1/; #remove brackets
>
> why ? where is it defined that DNs have <> brackets ?
There is a test case <UID=3Djsmith,O=3Dexample,C=3DUS> in the ldapbis =
document. I=20
don't know where such could be defined. Kurt?
--=20
Norbert Klasen, Dipl.-Inform.
DAASI International GmbH phone: +49 7071 29 70336
Wilhelmstr. 106 fax: +49 7071 29 5114
72074 T=FCbingen email: nor...@da...
Germany web: http://www.daasi.de
|
|
From: Chris R. <chr...@me...> - 2002-04-25 07:56:05
|
On 24/4/02 5:45 pm, Norbert Klasen <nor...@da...> wrote: >> why ? where is it defined that DNs have <> brackets ? > > There is a test case <UID=jsmith,O=example,C=US> in the ldapbis document. I > don't know where such could be defined. Kurt? The only time DNs are written with surrounding <> brackets is in running text; the angle brackets aren't actually part of the DN. This is part of RFC 1779 (last para of section 2.3), but I can't find it in RFC 2253. I don't think it is worth trying to cope with input DNs surrounded by angle brackets, but if it straightforward and doesn't slow things down... Cheers, Chris |
|
From: Graham B. <gb...@po...> - 2002-04-25 08:46:13
|
On Wed, Apr 24, 2002 at 06:45:31PM +0200, Norbert Klasen wrote:
> Hi Graham,
> I put the #xxxx issue in a separate mail.
>
> >> --- Util.pm-0.25_01 Tue Apr 23 20:35:04 2002
> >> +++ Util.pm Tue Apr 23 21:16:17 2002
> >> @@ -231,8 +231,8 @@
> >
> >> sub canonical_dn($%) {
> >> - my $dn = shift or return '';
> >> + my $dn = shift;
> >> + return $dn unless $dn; # empty DN or undef
> >
> > $dn = "0" ?
>
> This is another case to consider.
>
> > This should be return $dn unless $dn and length $dn;
>
> return $dn if $dn eq '' || !defined $dn ; # empty DN or undef
>
> This handles undef, '' and "0" (leads to an error later).
Yes, mine needs a defined added, which will make it -w clean too.
> > Does it really make sense for ldap_explode_dn todo the reverse ?
>
> I added a reverse option to ldap_explode_dn and though it would be a good
> idea to use it from canonical_dn as well. Am I missing something?
I am just not sure what the benefit of having reverse in ldap_explode_dn
is ? It was only ever in canonical_dn to make sorting DNs easier.
It anywan want the output of explode in reverse, then they can call reverse.
> >> sub ldap_explode_dn($%) {
> >> - my $dn = shift or return;
> >> + my @emptydn = (); #empty DN array for scalar context
> >> + my $dn = shift;
> >> + return wantarray ? [] : \@emptydn if $dn eq '';
> >
> > This does not make sense. You are returning a scalar ref
> > when wantarray is true. Did you mean
> >
> > return wantarray ? () : [] if $dn eq '';
>
> I'm not that familar with these elements of Perl so it tell you what a I
> actually had in mind: The return value of ldap_explode_dn should give the
> user an indication, whether an invalid DN was passed in. The problem is now
> that the (valid) empty DN '' explodes to an empty array. In the scalar
> context one can return undef or a reference to an empty array but I don't
> know to express this in list context.
Yup this is a common problem with context sensetive subs. If the user
cares about it they need to call it in a scalar context.
> >> my %opt = @_;
> >>
> >> my (@dn, %rdn);
> >> + $dn =~ s/^<(.*)>$/$1/; #remove brackets
> >
> > why ? where is it defined that DNs have <> brackets ?
>
> There is a test case <UID=jsmith,O=example,C=US> in the ldapbis document. I
> don't know where such could be defined. Kurt?
OK, fine.
Graham.
|
|
From: Graham B. <gb...@po...> - 2002-04-29 14:15:27
|
On Thu, Apr 25, 2002 at 09:44:42AM +0100, Graham Barr wrote:
> > >> sub ldap_explode_dn($%) {
> > >> - my $dn = shift or return;
> > >> + my @emptydn = (); #empty DN array for scalar context
> > >> + my $dn = shift;
> > >> + return wantarray ? [] : \@emptydn if $dn eq '';
> > >
> > > This does not make sense. You are returning a scalar ref
> > > when wantarray is true. Did you mean
> > >
> > > return wantarray ? () : [] if $dn eq '';
> >
> > I'm not that familar with these elements of Perl so it tell you what a I
> > actually had in mind: The return value of ldap_explode_dn should give the
> > user an indication, whether an invalid DN was passed in. The problem is now
> > that the (valid) empty DN '' explodes to an empty array. In the scalar
> > context one can return undef or a reference to an empty array but I don't
> > know to express this in list context.
>
> Yup this is a common problem with context sensetive subs. If the user
> cares about it they need to call it in a scalar context.
For this reason I propose that we remove context sensetivity from ldap_explode_dn
and always return an array ref, or undef on error. I belive it was
only ever there because ldap_canonical_dn used it, but ldap_canonical_dn
can just as easy use an array ref.
Graham.
|
|
From: Kurt D. Z. <Ku...@Op...> - 2002-04-23 21:04:36
|
At 01:07 PM 2002-04-23, Norbert Klasen wrote: >--On Dienstag, 23. April 2002 15:59 +0100 Graham Barr <gb...@po...>= wrote: > >>But you code also expanded >> >> CN=3D\a0 to 'CN' =3D> chr(160) >> >>Which means in canonical_dn both end up as >> >> CN=3D\a0 >> >>which is wrong >> >> CN=3D\a0 is not the same as CN=3D#a0 >> >>The first is a value of 1 character length and its type, for comaprisons, >>is the type of CN. The second is a value of unknown type and so cannot be >>compared to the first. > >After rereading RFC2253 it seems to me that CN should not be used as an= examaple here since it is a type that has a string representation. >One could argue that CN=3D#xxxx is illegal altogether. One can argue many things... # was specifically designed for CN (and other attributes of directoryString syntax). See section 7.2 of RFC 2253. The IETF LDAPbis WG is working on clarifying this. >>The #xxxxxx is normally a BER encodeing so to get the examples right >> >> CN=3D\01\01\42 is not the same as CN=3D#010142 nor is it the same >> as CN=3D\42 >> >>So you need to make sure that DNs of CN=3D#.... get returned from >>canonical_dn as #... and DN that don't start with # do not. > >As long as we do not want to make canonical_dn schema aware, I think it= should be enough for canonical_dn to encode AttributeTypes of the= dotted-decimal form as #xxxx. Additional attriubte types can be specified= by the (renamed) ber parameter. In our C API, we provide functions which do schema neutral normalizations. We don't convert between native string and BER value forms as that requires knowledge of schema. Instead, we just indicate whether the value is in native form or in BER form. We do convert the hex to an octet string containing the BER suitable for (BER) decoding. >One question that remains is whether and how ldap_explode_dn should mark= values exploded from #xxxx. (BTW do such things really occur in DNs?) I= would argue that there is no need for this: I would argue that if multiple encodings of the value can be returned (native v. BER), then there needs to be some indicatation as to which encoding is being used. >- Only AttributeValues which are of a type which does not have a string= representation defined for it are encoded as #xxxx. [RFC2253] No. >- "clients MUST NOT assume that an unrecognized syntax is a string= representation" [RFC2252] This statement is meant to imply that a client cannot assume that the native string encoding is displayable. For example, the native string encoding for audio is not displayable. >So an application that supports attribute types without a string= representation will know how to handle their values and therefore needs no= extra help by perl-ldap. No. PKI applications often have to use CN=3D# where the directory string choice is T61 (as transliteration between T.61 and UCS is not one-to-one). >Attached patch to perl-ldap-0.25_01: >- additional comments and documentation >- renamed binary parameter in canonical_dn to ber >- canonical_dn uses ldap_explode_dn reverse functionality >- #xxxx encode dotted-decimal attribute types >- don't use refs for #xxxx values >- handling of empty DNs > >--=20 >Norbert Klasen, Dipl.-Inform. >DAASI International GmbH phone: +49 7071 29 70336 >Wilhelmstr. 106 fax: +49 7071 29 5114 >72074 T=FCbingen email: nor...@da... >Germany web: http://www.daasi.de > > > |
|
From: Norbert K. <nor...@da...> - 2002-04-24 17:11:16
|
--On Dienstag, 23. April 2002 14:04 -0700 "Kurt D. Zeilenga"=20
<Ku...@Op...> wrote:
> At 01:07 PM 2002-04-23, Norbert Klasen wrote:
>> --On Dienstag, 23. April 2002 15:59 +0100 Graham Barr <gb...@po...>
># was specifically designed for CN (and other attributes of
> directoryString syntax). See section 7.2 of RFC 2253. The
> IETF LDAPbis WG is working on clarifying this.
> In our C API, we provide functions which do schema neutral
> normalizations. We don't convert between native string and
> BER value forms as that requires knowledge of schema. Instead,
> we just indicate whether the value is in native form or
> in BER form. We do convert the hex to an octet string containing
> the BER suitable for (BER) decoding.
After rerereading RFC2253 (this time including section 7.2 :-) I concur=20
with you. An indication that a value is in BER is required and Graham's=20
approach of making such values a reference seems to be a good way to do it.
How about this addition to the POD for ldap_explode_dn?
@@ -378,6 +365,43 @@
Explodes the given B<DN> into an array of hashes.
Returns undef if B<DN> is not a valid Distinguished Name.
+A Distinguished Name is a sequence of Relative Distingushed Names (RDNs),=20
which
+themselves are sets of Attributes. For each RDN a hash is constructed with =
the
+attribute type names as keys and the attribute values as corresponding=20
values.
+These hashes are then strored in an array in the order in which they=20
appear
+in the DN.
+
+For example, the DN 'OU=3DSales+CN=3DJ. Smith,DC=3Dexample,DC=3Dnet' is =
exploded=20
to:
+[
+ {
+ 'OU' =3D> 'Sales',
+ 'CN' =3D> 'J. Smith'
+ },
+ {
+ 'DC' =3D> 'example'
+ },
+ {
+ 'DC' =3D> 'net'
+ }
+]
+
+(RFC2253 string) DNs might also contain values, which are the bytes of the
+BER encoding of the X.500 AttributeValue rather than some LDAP string=20
syntax.
+These values are hex-encoded and prefixed with a #. To distingush such BER
+values, ldap_explode_dn uses references to the actual values,
+e.g. '1.3.6.1.4.1.1466.0=3D#04024869,DC=3Dexample,DC=3Dcom' is exploded =
to:
+[
+ {
+ '1.3.6.1.4.1.1466.0' =3D> \"\004\002Hi"
+ },
+ {
+ 'DC' =3D> 'example'
+ },
+ {
+ 'DC' =3D> 'com'
+ }
+];
+
It also performs the following operations on the given DN:
--=20
Norbert Klasen, Dipl.-Inform.
DAASI International GmbH phone: +49 7071 29 70336
Wilhelmstr. 106 fax: +49 7071 29 5114
72074 T=FCbingen email: nor...@da...
Germany web: http://www.daasi.de
|
|
From: Graham B. <gb...@po...> - 2002-04-25 08:47:16
|
On Wed, Apr 24, 2002 at 07:08:29PM +0200, Norbert Klasen wrote:
> --On Dienstag, 23. April 2002 14:04 -0700 "Kurt D. Zeilenga"
> <Ku...@Op...> wrote:
> > At 01:07 PM 2002-04-23, Norbert Klasen wrote:
> >> --On Dienstag, 23. April 2002 15:59 +0100 Graham Barr <gb...@po...>
>
> ># was specifically designed for CN (and other attributes of
> > directoryString syntax). See section 7.2 of RFC 2253. The
> > IETF LDAPbis WG is working on clarifying this.
>
> > In our C API, we provide functions which do schema neutral
> > normalizations. We don't convert between native string and
> > BER value forms as that requires knowledge of schema. Instead,
> > we just indicate whether the value is in native form or
> > in BER form. We do convert the hex to an octet string containing
> > the BER suitable for (BER) decoding.
>
> After rerereading RFC2253 (this time including section 7.2 :-) I concur
> with you. An indication that a value is in BER is required and Graham's
> approach of making such values a reference seems to be a good way to do it.
>
> How about this addition to the POD for ldap_explode_dn?
Seems good to me. I will gather everything from this thread and
patch the .pm
Graham.
>
> @@ -378,6 +365,43 @@
> Explodes the given B<DN> into an array of hashes.
> Returns undef if B<DN> is not a valid Distinguished Name.
>
> +A Distinguished Name is a sequence of Relative Distingushed Names (RDNs),
> which
> +themselves are sets of Attributes. For each RDN a hash is constructed with
> the
> +attribute type names as keys and the attribute values as corresponding
> values.
> +These hashes are then strored in an array in the order in which they
> appear
> +in the DN.
> +
> +For example, the DN 'OU=Sales+CN=J. Smith,DC=example,DC=net' is exploded
> to:
> +[
> + {
> + 'OU' => 'Sales',
> + 'CN' => 'J. Smith'
> + },
> + {
> + 'DC' => 'example'
> + },
> + {
> + 'DC' => 'net'
> + }
> +]
> +
> +(RFC2253 string) DNs might also contain values, which are the bytes of the
> +BER encoding of the X.500 AttributeValue rather than some LDAP string
> syntax.
> +These values are hex-encoded and prefixed with a #. To distingush such BER
> +values, ldap_explode_dn uses references to the actual values,
> +e.g. '1.3.6.1.4.1.1466.0=#04024869,DC=example,DC=com' is exploded to:
> +[
> + {
> + '1.3.6.1.4.1.1466.0' => \"\004\002Hi"
> + },
> + {
> + 'DC' => 'example'
> + },
> + {
> + 'DC' => 'com'
> + }
> +];
> +
> It also performs the following operations on the given DN:
>
>
>
> --
> Norbert Klasen, Dipl.-Inform.
> DAASI International GmbH phone: +49 7071 29 70336
> Wilhelmstr. 106 fax: +49 7071 29 5114
> 72074 Tübingen email: nor...@da...
> Germany web: http://www.daasi.de
>
>
|
|
From: Norbert K. <nor...@da...> - 2002-04-25 08:57:41
|
--On Donnerstag, 25. April 2002 09:44 +0100 Graham Barr <gb...@po...>=20 wrote: >> > Does it really make sense for ldap_explode_dn todo the reverse ? >> >> I added a reverse option to ldap_explode_dn and though it would be a >> good idea to use it from canonical_dn as well. Am I missing something? > > I am just not sure what the benefit of having reverse in ldap_explode_dn > is ? It was only ever in canonical_dn to make sorting DNs easier. > > It anywan want the output of explode in reverse, then they can call > reverse. OK, fine. --=20 Norbert Klasen, Dipl.-Inform. DAASI International GmbH phone: +49 7071 29 70336 Wilhelmstr. 106 fax: +49 7071 29 5114 72074 T=FCbingen email: nor...@da... Germany web: http://www.daasi.de |
|
From: Graham B. <gb...@po...> - 2002-04-23 10:21:25
|
On Tue, Apr 23, 2002 at 11:21:57AM +0200, Norbert Klasen wrote:
> --On Freitag, 19. April 2002 08:43 +0100 Graham Barr <gb...@po...>
> wrote:
> > Whats wrong with the subs in Net::LDAP::Utils ?
>
> ldap_explode_dn does not unescape escaped characters, e.g. the DN 'CN=\#John
> Smith\ ' becomes
> $VAR1 = {
> 'CN' => '\\#John Smith\\20'
> };
>
> instad of
>
> $VAR1 = {
> 'CN' => '#John Smith '
> };
Hm, I guess canonical_dn needs to be split from usinf explode_dn,
or explode_dn needs to be told not to expand. Otherwise you cannot tell the difference
between
CN=#a0
and
CN=\#a0
Do all testcases pass with your functions in place of the existing ones ?
Graham.
|
|
From: Graham B. <gb...@po...> - 2002-04-23 11:34:29
|
OK, I made a couple of tweaks and it passes the testsuite.
One change is that
CN=#0102
Now decodes as { CN => \"\01\02" }
That is the value is a reference. Ans canonical_dn regenerates it correctly.
Graham.
On Tue, Apr 23, 2002 at 11:19:40AM +0100, Graham Barr wrote:
> On Tue, Apr 23, 2002 at 11:21:57AM +0200, Norbert Klasen wrote:
> > --On Freitag, 19. April 2002 08:43 +0100 Graham Barr <gb...@po...>
> > wrote:
> > > Whats wrong with the subs in Net::LDAP::Utils ?
> >
> > ldap_explode_dn does not unescape escaped characters, e.g. the DN 'CN=\#John
> > Smith\ ' becomes
> > $VAR1 = {
> > 'CN' => '\\#John Smith\\20'
> > };
> >
> > instad of
> >
> > $VAR1 = {
> > 'CN' => '#John Smith '
> > };
>
> Hm, I guess canonical_dn needs to be split from usinf explode_dn,
> or explode_dn needs to be told not to expand. Otherwise you cannot tell the difference
> between
>
> CN=#a0
>
> and
>
> CN=\#a0
>
> Do all testcases pass with your functions in place of the existing ones ?
>
> Graham.
>
|
|
From: Kurt D. Z. <Ku...@Op...> - 2002-04-23 14:00:01
|
At 04:32 AM 2002-04-23, Graham Barr wrote:
>OK, I made a couple of tweaks and it passes the testsuite.
>
>One change is that
>
> CN=#0102
>
>Now decodes as { CN => \"\01\02" }
That's incorrect. The # format is hex encoded BER. The
first octet (01) is the (wrong) tag, the second is the data
length (02), and the data is missing. Hence, it cannot be
converted to the LDAP-specific encoding of the value.
>That is the value is a reference. Ans canonical_dn regenerates it correctly.
>
>Graham.
>
>On Tue, Apr 23, 2002 at 11:19:40AM +0100, Graham Barr wrote:
>> On Tue, Apr 23, 2002 at 11:21:57AM +0200, Norbert Klasen wrote:
>> > --On Freitag, 19. April 2002 08:43 +0100 Graham Barr <gb...@po...>
>> > wrote:
>> > > Whats wrong with the subs in Net::LDAP::Utils ?
>> >
>> > ldap_explode_dn does not unescape escaped characters, e.g. the DN 'CN=\#John
>> > Smith\ ' becomes
>> > $VAR1 = {
>> > 'CN' => '\\#John Smith\\20'
>> > };
>> >
>> > instad of
>> >
>> > $VAR1 = {
>> > 'CN' => '#John Smith '
>> > };
>>
>> Hm, I guess canonical_dn needs to be split from usinf explode_dn,
>> or explode_dn needs to be told not to expand. Otherwise you cannot tell the difference
>> between
>>
>> CN=#a0
>>
>> and
>>
>> CN=\#a0
>>
>> Do all testcases pass with your functions in place of the existing ones ?
>>
>> Graham.
>>
|
|
From: Graham B. <gb...@po...> - 2002-04-23 14:02:29
|
On Tue, Apr 23, 2002 at 06:59:55AM -0700, Kurt D. Zeilenga wrote:
> At 04:32 AM 2002-04-23, Graham Barr wrote:
> >OK, I made a couple of tweaks and it passes the testsuite.
> >
> >One change is that
> >
> > CN=#0102
> >
> >Now decodes as { CN => \"\01\02" }
>
> That's incorrect. The # format is hex encoded BER. The
> first octet (01) is the (wrong) tag, the second is the data
> length (02), and the data is missing. Hence, it cannot be
> converted to the LDAP-specific encoding of the value.
I know this is a bad BER example. What I was trying to show is that the value
is decoded into bytes, but the structure holds a reference so that it knows
it has to encode it back as #\01\02
Graham.
> >That is the value is a reference. Ans canonical_dn regenerates it correctly.
> >
> >Graham.
> >
> >On Tue, Apr 23, 2002 at 11:19:40AM +0100, Graham Barr wrote:
> >> On Tue, Apr 23, 2002 at 11:21:57AM +0200, Norbert Klasen wrote:
> >> > --On Freitag, 19. April 2002 08:43 +0100 Graham Barr <gb...@po...>
> >> > wrote:
> >> > > Whats wrong with the subs in Net::LDAP::Utils ?
> >> >
> >> > ldap_explode_dn does not unescape escaped characters, e.g. the DN 'CN=\#John
> >> > Smith\ ' becomes
> >> > $VAR1 = {
> >> > 'CN' => '\\#John Smith\\20'
> >> > };
> >> >
> >> > instad of
> >> >
> >> > $VAR1 = {
> >> > 'CN' => '#John Smith '
> >> > };
> >>
> >> Hm, I guess canonical_dn needs to be split from usinf explode_dn,
> >> or explode_dn needs to be told not to expand. Otherwise you cannot tell the difference
> >> between
> >>
> >> CN=#a0
> >>
> >> and
> >>
> >> CN=\#a0
> >>
> >> Do all testcases pass with your functions in place of the existing ones ?
> >>
> >> Graham.
> >>
>
|
|
From: Norbert K. <nor...@da...> - 2002-04-23 12:35:41
|
--On Dienstag, 23. April 2002 11:19 +0100 Graham Barr <gb...@po...>=20 wrote: > Hm, I guess canonical_dn needs to be split from usinf explode_dn, > or explode_dn needs to be told not to expand. Otherwise you cannot tell > the difference between > > CN=3D#a0 > > and > > CN=3D\#a0 My version of ldap_explode_dn also unescapes "^#(hexpair)+". 'CN=3D#a0' is 'CN=3D\a0' and 'CN=3D\#a0' is 'CN=3D\23a0' > Do all testcases pass with your functions in place of the existing ones ? There is one false positiv left: '01.1=3Djsmith' There was a typo in ldap_explode_dn which prevented lower casing from=20 working. I also update the return code handling in case of an error and=20 added a reverse parameter to ldap_explode_dn as well as support for the=20 '<UID=3Djsmith,O=3Dexample,C=3DUS>' LDAPv2-ism. Attached is the updated version of dnutils.pm and a test script along with=20 the test cases from ldapbis. --=20 Norbert Klasen, Dipl.-Inform. DAASI International GmbH phone: +49 7071 29 70336 Wilhelmstr. 106 fax: +49 7071 29 5114 72074 T=FCbingen email: nor...@da... Germany web: http://www.daasi.de |
|
From: Graham B. <gb...@po...> - 2002-04-23 12:43:45
|
On Tue, Apr 23, 2002 at 02:33:02PM +0200, Norbert Klasen wrote: > > > --On Dienstag, 23. April 2002 11:19 +0100 Graham Barr <gb...@po...> > wrote: > > > Hm, I guess canonical_dn needs to be split from usinf explode_dn, > > or explode_dn needs to be told not to expand. Otherwise you cannot tell > > the difference between > > > > CN=#a0 > > > > and > > > > CN=\#a0 > > My version of ldap_explode_dn also unescapes "^#(hexpair)+". > 'CN=#a0' is 'CN=\a0' and 'CN=\#a0' is 'CN=\23a0' But that is the problem 'CN=#a0' and 'CN=\a0' are not the same and should not be made equal. > > Do all testcases pass with your functions in place of the existing ones ? > > There is one false positiv left: '01.1=jsmith' I am not too bother about false positives, we should be liberal in what we accept. Graham. |
|
From: Norbert K. <nor...@da...> - 2002-04-23 14:54:49
|
--On Dienstag, 23. April 2002 13:42 +0100 Graham Barr <gb...@po...>=20 wrote: >> > CN=3D#a0 >> > >> > and >> > >> > CN=3D\#a0 >> >> My version of ldap_explode_dn also unescapes "^#(hexpair)+". >> 'CN=3D#a0' is 'CN=3D\a0' and 'CN=3D\#a0' is 'CN=3D\23a0' > > But that is the problem 'CN=3D#a0' and 'CN=3D\a0' are not the same and > should not be made equal. There are not made equal: 'CN=3D#a0' gets exploded to 'CN' =3D> chr(160); 'CN=3D\#a0' gets exploded to 'CN' =3D> '#a0' --=20 Norbert Klasen, Dipl.-Inform. DAASI International GmbH phone: +49 7071 29 70336 Wilhelmstr. 106 fax: +49 7071 29 5114 72074 T=FCbingen email: nor...@da... Germany web: http://www.daasi.de |
|
From: Graham B. <gb...@po...> - 2002-04-23 15:01:33
|
On Tue, Apr 23, 2002 at 03:33:35PM +0200, Norbert Klasen wrote: > > > --On Dienstag, 23. April 2002 13:42 +0100 Graham Barr <gb...@po...> > wrote: > > >> > CN=#a0 > >> > > >> > and > >> > > >> > CN=\#a0 > >> > >> My version of ldap_explode_dn also unescapes "^#(hexpair)+". > >> 'CN=#a0' is 'CN=\a0' and 'CN=\#a0' is 'CN=\23a0' > > > > But that is the problem 'CN=#a0' and 'CN=\a0' are not the same and > > should not be made equal. > > There are not made equal: > 'CN=#a0' gets exploded to 'CN' => chr(160); > 'CN=\#a0' gets exploded to 'CN' => '#a0' But you code also expanded CN=\a0 to 'CN' => chr(160) Which means in canonical_dn both end up as CN=\a0 which is wrong CN=\a0 is not the same as CN=#a0 The first is a value of 1 character length and its type, for comaprisons, is the type of CN. The second is a value of unknown type and so cannot be compared to the first. The #xxxxxx is normally a BER encodeing so to get the examples right CN=\01\01\42 is not the same as CN=#010142 nor is it the same as CN=\42 So you need to make sure that DNs of CN=#.... get returned from canonical_dn as #... and DN that don't start with # do not. Graham. |
|
From: Graham B. <gb...@po...> - 2002-04-23 15:08:51
|
I also meant to say that you code, with this change, is already in http://monty.mutatus.co.uk/~gbarr/perl-ldap-0.25_01.tar.gz And it would be helpful if any fixes we done as patches against that distribution. Graham. On Tue, Apr 23, 2002 at 03:59:59PM +0100, Graham Barr wrote: > On Tue, Apr 23, 2002 at 03:33:35PM +0200, Norbert Klasen wrote: > > > > > > --On Dienstag, 23. April 2002 13:42 +0100 Graham Barr <gb...@po...> > > wrote: > > > > >> > CN=#a0 > > >> > > > >> > and > > >> > > > >> > CN=\#a0 > > >> > > >> My version of ldap_explode_dn also unescapes "^#(hexpair)+". > > >> 'CN=#a0' is 'CN=\a0' and 'CN=\#a0' is 'CN=\23a0' > > > > > > But that is the problem 'CN=#a0' and 'CN=\a0' are not the same and > > > should not be made equal. > > > > There are not made equal: > > 'CN=#a0' gets exploded to 'CN' => chr(160); > > 'CN=\#a0' gets exploded to 'CN' => '#a0' > > But you code also expanded > > CN=\a0 to 'CN' => chr(160) > > Which means in canonical_dn both end up as > > CN=\a0 > > which is wrong > > CN=\a0 is not the same as CN=#a0 > > The first is a value of 1 character length and its type, for comaprisons, > is the type of CN. The second is a value of unknown type and so cannot be > compared to the first. > > The #xxxxxx is normally a BER encodeing so to get the examples right > > CN=\01\01\42 is not the same as CN=#010142 nor is it the same > as CN=\42 > > So you need to make sure that DNs of CN=#.... get returned from canonical_dn > as #... and DN that don't start with # do not. > > Graham. > |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X