perl-ldap-dev

Re: utility functions for handling Distinguished Names

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

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

Re: utility functions for handling Distinguished Names

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

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.

RE: mod_perl problems

[<la...@sp...>]

Hi Harikrishnan,

>Check the error_log of apache and you might get some hints
>on why apache gives the error. Always check the errorlog.

Did so - but no clues this time.

>(Guess =231)
>CGI and mod_perl environments are not exactly the same.
>I have seen problems if my script is =27forking=27 and=20
>invoking another script (even indirectly). STDIN and STDOUT
>file descriptors are messed up in mod_perl 1.26. So
>open(=22=7C...=22) would also fail under mod_perl.=20

This is mod_perl 1.25.

>(Guess =232)
>mod_perl doesn=27t add the standard HTTP headers unless you
>have SendHeaders option ( I forget the exact name - check
>mod_perl documentation). What this means is that you
>script would have to print *all* HTTP headers in addition
>to printing the Content-Type and so on.. This includes the
>HTTP status line.Received: from Skjaerlund-MTA by porter.spinn.dk
 Whenever apache detects that some response
>doesn=27t have adequate headers, it will prints =22internal server
>error=22.

I=27ll remember that one.

Anyway, my problem is solved - due to a weird problem, my =24UserName
variable got the wrong value in some situations.

Accordingly, I got an anonymous login instead of an authorized - and
the query didn=27t return any results.

So the function =24result->entry(0)->get_value() didn=27t exist, and the
script halted; quite fair.

What I don=27t understand now is that I tried the following construct:

if (=24result->entry(0)) =7B
  =40ACL =3D =40=7B=24result->entry(0)->get_value(=27ACL=27, asref=3D>1)=7D=
;
=7D

That test proves positive even though entry(0) doesn=27t exist - and it
tries to execute my code. How come?

Thanks for your interest so far.

Regards,
Lars

Lars Skj=E6rlund, Network Consultant, Spinn International ApS
Bukkeballevej 30, 2960 Rungsted Kyst, Denmark
Tel.: +45 70 25 88 10, Fax: +45 70 25 88 44
Mail: lars=40spinn.dk Web: http://www.spinn.dk
--

Re: utility functions for handling Distinguished Names

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

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

[±¤_°í]Àü´ÜÁöÀμ⠽ÃÁß°¡°ÝÀÇ Àý¹Ý°ªÀ¸·Î..

[114ÇÁ¸°Æ®´åÄÄ<chh...@ha...>]

<html>
<head>
<title>114프린트닷컴</title>
<meta http-equiv="Content-Type" content="text/html; charset=euc-kr">
</head>
<body bgcolor="#FFFFFF">
<table width="600" border="0" cellspacing="0" cellpadding="0">
<tr>
<td><img src="http://rgprint.co.kr/images/114print_1.gif" width="600" height="165"></td>
</tr>
<tr>
<td><img src="http://rgprint.co.kr/images/114print_2.gif" width="600" height="123"></td>
</tr>
<tr>
<td><img src="http://rgprint.co.kr/images/114print_3.gif" width="600" height="214"></td>
</tr>
<tr>
<td><img src="http://rgprint.co.kr/images/114print_4.gif" width="600" height="165"></td>
</tr>
<tr>
<td><img src="http://rgprint.co.kr/images/114print_5.gif" width="600" height="149"></td>
</tr>
<tr>
<td><img src="http://rgprint.co.kr/images/114print_6.gif" width="600" height="134"></td>
</tr>
<tr>
<td><img src="http://rgprint.co.kr/images/114print_7.gif" width="600" height="69" usemap="#Map" border="0"><map name="Map"><area shape="rect" coords="217,3,337,69" href="http://www.114print.com" target="_blank"></map></td>
</tr>
<tr>
<td>
<div align="center"><font size="2"><br>
본 메일은 정보통신망 이용촉진 및 정보보호 등에 관한 법률 제 50조에 의거한 [광고] 메일입니다. <br>
귀하의 생활과 사업활동에 도움이 될수 있는 정보였으면 합니다. 도움이 되지않는 정보라면<br>
사과말씀드리며, <a href="mailto:chh...@ha...?subject=수신거부">수신거부</a>
하여주시면 다시는 보내지 않을것을 약속드립니다. </font></div>
</td>
</tr>
</table>
</body>
</html>

Re: utility functions for handling Distinguished Names

[Norbert K. <nor...@da...>]

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

Re: utility functions for handling Distinguished Names

[Norbert K. <nor...@da...>]

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

Re: Changing passwords in Active Directory

[Norbert K. <nor...@da...>]

--On Mittwoch, 24. April 2002 10:28 -0400 Jim Harle <ha...@us...> wrote:

> Does anyone have a code snippet of changing passwords in Active Directory
> via Net::LDAP?  From what I can gather, you need 1) to have 128 bit SSL
> connection

Yes

> 2) have either old and new password or be bound with Reset
> Password rights


Yes

> 3) put things out correctly for changing the
> unicodePwd attribute. I am unsure as to how to use an old password (is it
> part of a modify or do we need to bind with it?)

IIRC if you don't have reset password rights on the account, you do (in=20
LDIF notation):

changetype: modify
delete: unicodePwd
unicodePwd: MakeUnicodePwd(OldPassword)
-
add: unicodePwd
unicodePwd: MakeUnicodePwd(NewPassword)

otherwise you do a simple_bind as someone who das reset password rights=20
(self) and do a replace.

> and how to format the new
> password correctly for unicodePwd.

use Unicode::String qw(latin1 utf16);
sub MakeUnicodePwd
{
    my $u =3D latin1("\"".$_[0]."\"");
    $u->byteswap();
    return $u->ucs2;
}


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

Re: Changing passwords in Active Directory

[Christopher A B. <ca...@tc...>]

As Jim Harle once put it so eloquently:

> Does anyone have a code snippet of changing passwords in Active Directory
> via Net::LDAP?  From what I can gather, you need 1) to have 128 bit SSL
> connection 2) have either old and new password or be bound with Reset
> Password rights and 3) put things out correctly for changing the
> unicodePwd attribute.  I am unsure as to how to use an old password (is it
> part of a modify or do we need to bind with it?) and how to format the new
> password correctly for unicodePwd.

This is how you can do it if you are bound via LDAPS with sufficient
(administratorish?) rights.  I've never tried to do this as a user
changing their own password (our AD is slaved to our X.500 directory,
so all changes come from X.500 via the script from which this was
taken).  But this shows you how you can format unicodePwd so that AD
will take the change.

&change_changes is there because when you do a "replace" on an
attribute of an Entry object, it adds a "replace" action to the entry
rather than modifying an existing "replace" command, which would
result in AD trying to modify unicodePwd twice; once with the original 
(plaintext) value, and once with the "fixed" version.  The first
modify would cause an error that would cause the whole operation to be 
rejected.  So we have to dig a little in the actual Entry structure.
If you're not reusing an existing Entry object (i.e. you're building
one from scratch) or you're directly updating the entry, the
change_changes bit isn't necessary.

  # done; now, if there's still a unicodePwd, then UTF-16(?) it
  # and base64 encode it and make sure it gets sent that way.
  my $opw = $entry->get_value('unicodePwd');
  if (defined $opw) {
    my $upw = pack "v*", unpack "C*", qq("$opw");
    &change_changes($entry, 'replace', 'unicodePwd', $upw);
  }

sub change_changes {
  my ($entry, $op, $attr, @values) = @_;
  
  # add/delete entry operations don't have this problem
  # so just use the regular method to update them
  unless ($entry->changetype eq 'modify') {
    $entry->$op($attr, \@values);
    return;
  }

  # ok, this is a modify, do it the hard way
  $attr = lc $attr;
  my $changes = $entry->{changes};
  for (my $i = 0; $i < @$changes; $i += 2) {
    my ($oldop, $oldargs)   = @{$changes}[$i, $i+1];
    my ($oldattr, $oldvals) = @$oldargs;
    if ($oldattr eq $attr) {
      $changes->[$i] = $op;
      $oldargs->[1] = \@values;
      last;
    }
  }
}

%%  Christopher A. Bongaarts  %%  ca...@tc...       %%
%%  Internet Services         %%  http://umn.edu/~cab  %%
%%  University of Minnesota   %%  +1 (612) 625-1809    %%

RE: mod_perl problems

[Harikrishnan B. <har...@jp...>]

Check the error_log of apache and you might get some hints
on why apache gives the error. Always check the errorlog.

(Guess #1)
CGI and mod_perl environments are not exactly the same.
I have seen problems if my script is 'forking' and=20
invoking another script (even indirectly). STDIN and STDOUT
file descriptors are messed up in mod_perl 1.26. So
open("|...") would also fail under mod_perl.=20

(Guess #2)
mod_perl doesn't add the standard HTTP headers unless you
have SendHeaders option ( I forget the exact name - check
mod_perl documentation). What this means is that you
script would have to print *all* HTTP headers in addition
to printing the Content-Type and so on.. This includes the
HTTP status line. Whenever apache detects that some response
doesn't have adequate headers, it will prints "internal server
error".

> -----Original Message-----
> From: Lars Skj=E6rlund [mailto:la...@sp...]
> Sent: Wednesday, April 24, 2002 3:37 AM
> To: per...@li...
> Subject: mod_perl problems
>=20
>=20
> Hi list,
>=20
> I'm writing some code to ask LDAP a few questions and show the result
> in a browser.
>=20
> My code works fine in standalone mode as well as a common CGI-script,
> but when running under mod_perl with Apache, it halts with an=20
> "Internal
> Server Error":
>=20
> $result =3D $ldap->search(base=3D>"c=3D$ldapCountry", scope=3D>'one',
> filter=3D>"o=3D$ldapOrg", attrs=3D>'ACL');
>  =20
> my @ACL =3D @{$result->entry(0)->get_value('ACL', asref=3D>1)};
>=20
> The first line executes fine, $result->error reports=20
> 'Success', but the
> next line halts the script.
>=20
> Anybody's any idea about what goes wrong?
>=20
> Regards,
> Lars
>=20
> Lars Skj=E6rlund, Network Consultant, Spinn International ApS
> Bukkeballevej 30, 2960 Rungsted Kyst, Denmark
> Tel.: +45 70 25 88 10, Fax: +45 70 25 88 44
> Mail: lars@sReceived: from Skjaerlund-MTA by porter.spinn.dk
> pinn.dk Web: http://www.spinn.dk
> --
>=20

Changing passwords in Active Directory

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

Does anyone have a code snippet of changing passwords in Active Directory
via Net::LDAP?  From what I can gather, you need 1) to have 128 bit SSL
connection 2) have either old and new password or be bound with Reset
Password rights and 3) put things out correctly for changing the
unicodePwd attribute.  I am unsure as to how to use an old password (is it
part of a modify or do we need to bind with it?) and how to format the new
password correctly for unicodePwd.
  --Jim Harle

How do I use Parser DSML?

[Carlos F. B. <car...@re...>]

Hello friends,

	Could anybody send me a example of some program which it's using the =

Parser DSML, to achieve a entry LDAP from DSML file?, or something that c=
ould =

help me to translate DSML to entry LDAP.

Thanks and regards, Carlos

 ______________               __          _____________________________
                             /_/
 Carlos Fuentes Bermejo __            __   car...@re...
 RedIRIS/CSIC          /_/  RedIRIS  /_/   Tel:   + 34 915855124
 Serrano,142                 __            Fax:   + 34 915855146
 28006  Madrid              /_/            http://www.rediris.es
 SPAIN                                     Sistemas de Informaci=F3n - =

                                           Redes Tem=E1ticas =

					   Co-Responsable de Correo
					   Electr=F3nico	=

____________ Spanish Academic & Research Network ___________________

mod_perl problems

[<la...@sp...>]

Hi list,

I=27m writing some code to ask LDAP a few questions and show the result
in a browser.

My code works fine in standalone mode as well as a common CGI-script,
but when running under mod_perl with Apache, it halts with an =22Internal
Server Error=22:

=24result =3D =24ldap->search(base=3D>=22c=3D=24ldapCountry=22, =
scope=3D>=27one=27,
filter=3D>=22o=3D=24ldapOrg=22, attrs=3D>=27ACL=27);
 =20
my =40ACL =3D =40=7B=24result->entry(0)->get_value(=27ACL=27, asref=3D>1)=
=7D;

The first line executes fine, =24result->error reports =27Success=27, but =
the
next line halts the script.

Anybody=27s any idea about what goes wrong?

Regards,
Lars

Lars Skj=E6rlund, Network Consultant, Spinn International ApS
Bukkeballevej 30, 2960 Rungsted Kyst, Denmark
Tel.: +45 70 25 88 10, Fax: +45 70 25 88 44
Mail: lars=40sReceived: from Skjaerlund-MTA by porter.spinn.dk
pinn.dk Web: http://www.spinn.dk
--

NMAS simple password?

[C. L. <cl...@ca...>]

I'm looking at creating a password changing page that will change *both* a 
user's NDS password and their "simple" (hashless) password used for Native 
File Access.

I have the Novell LDAP server up and running.  I can successfully change a 
users' NDS password by modifying the attribute "userPassword".  I can't 
find much info, tho, on changing the simple password, what attribute it 
might be, etc.  A quick look in the newsgroups shows an example, but using 
C and invoking a special server side control.

Has anyone tried this with perl-ldap?  Has anyone had any success?  ^_^

	- C. Liang
	  Desktop Network Admin, ITS
	  Carleton College

Re: utility functions for handling Distinguished Names

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

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

Re: utility functions for handling Distinguished Names

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

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.

Re: utility functions for handling Distinguished Names

[Norbert K. <nor...@da...>]

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

Re: utility functions for handling Distinguished Names

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

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

Re: utility functions for handling Distinguished Names

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

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.

Re: utility functions for handling Distinguished Names

[Norbert K. <nor...@da...>]

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

Re: utility functions for handling Distinguished Names

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

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

Re: utility functions for handling Distinguished Names

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

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

[±¤ °í]°¡¿ä¸¦ ¹«·á,½Ç½Ã°£À¸·Î ÀÛ°îÇص帳´Ï´Ù.Compose4U.com

[Compose4U<te...@te...>]

<HTML><HEAD><TITLE>▥▥▥ www.compose4u.com
▥▥▥</TITLE><META HTTP-EQUIV='Content-Type'
CONTENT='text/html; charset=euc-kr'><link rel='stylesheet'
href='http://www.compose4u.com/compose4u.css'
type='text/css'></HEAD><tr><td>&nbsp;</td></tr><tr width=100% height=100% ><td  BGCOLOR=#FFFFFF topmargin=0
leftmargin=0><TABLE WIDTH=600 BORDER=0 CELLPADDING=0
CELLSPACING=0><TR><TD><IMG
SRC='http://www.compose4u.com/smail/images/spacer.gif'
WIDTH=99 HEIGHT=1></TD><TD><IMG
SRC='http://www.compose4u.com/smail/images/spacer.gif'
WIDTH=21 HEIGHT=1></TD><TD><IMG
SRC='http://www.compose4u.com/smail/images/spacer.gif'
WIDTH=295 HEIGHT=1></TD><TD><IMG
SRC='http://www.compose4u.com/smail/images/spacer.gif'
WIDTH=106 HEIGHT=1></TD><TD><IMG
SRC='http://www.compose4u.com/smail/images/spacer.gif'
WIDTH=79 HEIGHT=1></TD></TR><TR><TD COLSPAN=2 ROWSPAN=2><A
HREF='http://www.compose4u.com'><IMG
SRC='http://www.compose4u.com/smail/images/smail_01.gif'
WIDTH=120 HEIGHT=98 BORDER=0></A></TD><TD ROWSPAN=2><IMG
SRC='http://www.compose4u.com/smail/images/smail_02.gif'
WIDTH=295 HEIGHT=98></TD><TD COLSPAN=2><IMG
SRC='http://www.compose4u.com/smail/images/smail_03.gif'
WIDTH=185 HEIGHT=79></TD></TR><TR><TD COLSPAN=2><A
HREF='http://www.compose4u.com'><IMG
SRC='http://www.compose4u.com/smail/images/smail_04.gif'
WIDTH=185 HEIGHT=19 BORDER=0></A></TD></TR><TR><TD
COLSPAN=5><IMG
SRC='http://www.compose4u.com/smail/images/smail_05.gif'
WIDTH=600 HEIGHT=45></TD></TR><TR><TD>	<IMG
SRC='http://www.compose4u.com/smail/images/smail_06.gif'
WIDTH=99 HEIGHT=242></TD><TD COLSPAN=3 WIDTH=422
HEIGHT=242><object
classid='clsid:D27CDB6E-AE6D-11cf-96B8-444553540000'
codebase='http://download.macromedia.com/pub/shockwave/cabs/
flash/swflash.cab#version=4,0,2,0' width='422'
height='242'><param name=movie
value='http://www.compose4u.com/smail/images/test2.swf'>
<param name=menu value=false><embed
src='http://www.compose4u.com/smail/images/test2.swf'
quality=high
pluginspage='http://www.macromedia.com/shockwave/download/in
dex.cgi?P1_Prod_Version=ShockwaveFlash'
type='application/x-shockwave-flash' width='422'
height='242'></embed></object></td><TD><IMG
SRC='http://www.compose4u.com/smail/images/smail_08.gif'
WIDTH=79 HEIGHT=242></TD></TR><TR><TD
background='http://www.compose4u.com/smail/images/smail_09.gif' COLSPAN=5 WIDTH=600 >
<div align='center'><br>
<p class='z'><span class='a'><font color='#996600'>나만의
<font color='#FF3300'><b>주제가</b></font>를 원하는 <font
color='#FF3300'><b>장르와 분위기</b></font>로 즉석에서
<font color='#FF3300'><b>무료</b></font>로 만들어
드립니다.<br></font></span><font color='#996600'><b><a
href='http://www.compose4u.com'>www.compose4u.com</a></b>
<span class='a'><br>          <font color='#333399'>(현직
공중파 방송 PD, 작가, 영화감독이 주축이 되어 만든
사이트입니다.</font></span></font><font
color='#333399'><span
class='a'>)</span></font></p></div></TD></TR><TR><TD
COLSPAN=5><IMG
SRC='http://www.compose4u.com/smail/images/smail_10.gif'
WIDTH=600 HEIGHT=40></TD></TR><TR><TD COLSPAN=5><IMG
SRC='http://www.compose4u.com/smail/images/smail_11.gif'
WIDTH=600 HEIGHT=23></TD></TR><TR><TD
background='http://www.compose4u.com/smail/images/smail_16.gif' COLSPAN=5 WIDTH=600  nowrap><blockquote><p><font
color='#660000'><span class='a'><font
color='#660066'>자신이 원하는 대로 즉석에서 창작가요를
만들수 있슴.</font></span></font><font
color='#660066'><span class='a'></span></font><span
class='a'><br><br><b><font color='#FF9933'>용도
:</font><font color='#660000'> </font></b><font
color='#660000'>  나만의 주제가, 사랑 고백, 공개청혼,
자화자찬용 노래, 승진 입학 졸업 등 <br> 각종 축하용 노래,
빚 독촉, 공갈 협박, 비밀폭로용 노래, 대통령,국회의원, <br>
시의원, 구의원 심지어 초등학교 반장선거에 이르기까지 각종
선거시 선거송<br> 그외 미아찾기, 집나간 마누라 찾기,
비밀결사단체의 공개지령, <br> 폭도선동용 노래로 쓰인다는
말도 있슴.
</font></span></p></blockquote></TD></TR><TR><TD
COLSPAN=5>			<IMG
SRC='http://www.compose4u.com/smail/images/smail_12.gif'
WIDTH=600 HEIGHT=23></TD></TR><TR><TD
background='http://www.compose4u.com/smail/images/smail_16.gif' COLSPAN=5 WIDTH=600 nowrap> <blockquote><p><font
color='#660000'><span class='a'><font
color='#660066'>자신이 만든          나만의 창작가요를
노래방 형태의 이메일로 보낼수 있슴.
</font></span></font></p></blockquote></TD></TR><TR><TD
COLSPAN=5><IMG
SRC='http://www.compose4u.com/smail/images/smail_13.gif'
WIDTH=600 HEIGHT=23></TD></TR><TR><TD
background='http://www.compose4u.com/smail/images/smail_16.gif' COLSPAN=5 WIDTH=600 nowrap> <blockquote><p><font
color='#660000'><span class='a'><font
color='#660066'>자신이 만든   창작가요에 본인이 노래까지
녹음하여 핸드폰으로 보낼수 있슴.
</font></span></font></p></blockquote></TD></TR><TR><TD
COLSPAN=5><IMG
SRC='http://www.compose4u.com/smail/images/smail_15.gif'
WIDTH=600 HEIGHT=12></TD></TR><TR><TD
background='http://www.compose4u.com/smail/images/smail_16.gif' COLSPAN=5 WIDTH=600 nowrap>  <blockquote> <br><font
color='#CCCC66'><a href='http://www.compose4u.com'><span
class='a'>www.compose4u.com</span></a></font><font
color='#CC9900'><span class='a'>         에선 내가
원하는대로 창작가요를 만들어 핸드폰, e메일로 보내기까지
모든것이 실시간, 즉석으로 이루어집니다. <br>  <br>  또한
상업음반의 가수나 작사가로 데뷔할 꿈이 있는 분들은 필히 <a
href='http://www.compose4u.com'>www.compose4u.com</a>으로
오세요.</span></font> <font color='#CC9900'><span
class='a'><br><br><a
href='http://www.compose4u.com'>www.compose4u.com</a>
오디션을 통해 공중파 드라마와         시트콤의 배경음악과
주제가로 쓰일 노래의 가수와 작사가로 데뷔 시켜 드립니다.
</span></font></blockquote></TD></TR><TR><TD
COLSPAN=5>	<IMG
SRC='http://www.compose4u.com/smail/images/smail_15.gif'
WIDTH=600 HEIGHT=12></TD></TR>  <TR> <TD
background='http://www.compose4u.com/smail/images/smail_16.gif' COLSPAN=5 WIDTH=600 nowrap>
&nbsp;<br></td></tr><TR><TD COLSPAN=5><IMG
SRC='http://www.compose4u.com/smail/images/smail_18.gif'
WIDTH=600 HEIGHT=35></TD></TR><TR> <TD
background='http://www.compose4u.com/smail/images/smail_19.gif' COLSPAN=5 WIDTH=600 nowrap>  <blockquote><br><font
color='#18599C' ><span class='z'>현재 시범 서비스 기간
이벤트로<font color='#FF0000'>  10곡</font>을 만들어
부르시면 </span></font> <span class='z'><font
color='#18599C' >예쁜  쟈켓의 <font
color='#FF0000'>CD앨범</font>으로 제작해 보내드립니다.
</font> <font color='#18599C' >이벤트 기간 중에 전국
배송비 포함 <font color='#FF0000'>꽁짜</font>~!</font>
</span><br></blockquote></TD></TR><TR><TD COLSPAN=5><IMG
SRC='http://www.compose4u.com/smail/images/smail_21.gif'
WIDTH=600 HEIGHT=6></TD></TR><TR><TD
background='http://www.compose4u.com/smail/images/smail_22.gif' COLSPAN=5 WIDTH=600 nowrap><blockquote><br><font
color='#006600'> <span class='a'><font color='#000000'>*
메일은  <font color='#FF6600'>1회성</font>의
광고메일입니다. 굳이 수신거부를 하지 않으셔도 재차 발송은
없을  것입니다. *<br>  발송된 주소는 웹사이트상에서
검색/수집된 자료이므로 전자우편 정보 이외에 어떠한 정보도
없음을 알려 드립니다. 메일 수신을 원하시지 않으시면
수신거부를 클릭하신후 메일 주소를 입력하여주시기
바랍니다.</font></span></font><span class='a'><b
class='z'><font color='#FF6600'><a
href='http://www.compose4u.com/spam/rejectmail.jsp'>
[수신거부]</a></font></b> </span> <br></blockquote>
</TD></TR><TR>	<TD COLSPAN=5>	<A
HREF='http://www.compose4u.com'><IMG
SRC='http://www.compose4u.com/smail/images/smail_24.gif'
WIDTH=600 HEIGHT=37
BORDER=0></A></TD></TR></TABLE></BODY></HTML>

Re: utility functions for handling Distinguished Names

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

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.

Re: utility functions for handling Distinguished Names

[Norbert K. <nor...@da...>]

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