Skip Menu |

This queue is for tickets about the perl-ldap CPAN distribution.

Report information
The Basics
Id: 81380
Status: resolved
Priority: 0/
Queue: perl-ldap
People
Owner: Nobody in particular
Requestors: peter [...] pjsc.de
Cc:
AdminCc:
Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: 0.51

History Show all quoted text
  Fri Nov 23 11:16:03 2012 peter [...] pjsc.de - Ticket created
Subject: is subroutine _unescape correct?
Module Net::LDAP::Filter I got some problems with a filter like this (uniquemember=uid=1234+456,c=de,ou=test,o=company.com) I get an invalid DN syntax exception from the server. While looking into to it, I found some difference between the documentation of _unescape and the regex itself: Documentation: # Unescape # \xx where xx is a 2-digit hex number # \y where y is one of ( ) \ * regex: sub _unescape { $_[0] =~ s/ \\([\da-fA-F]{2}|.) /.... well this regex matches any string with a \ and another character and not only ( ) \ * for the next character \\([\da-fA-F]{2}|[()\\*]) seems to be more like the documentation. And this change fixed my problem.
  Fri Nov 23 16:35:31 2012 peter [...] adpm.de - Correspondence added
Subject: Re: [rt.cpan.org #81380] is subroutine _unescape correct?
Date: Fri, 23 Nov 2012 22:42:36 +0100
To: bug-perl-ldap [...] rt.cpan.org
From: Peter Marschall <peter [...] adpm.de>
Hi, On Friday, 23. November 2012, you wrote: Show quoted text
> [...] > I got some problems with a filter like this > (uniquemember=uid=1234+456,c=de,ou=test,o=company.com) > > I get an invalid DN syntax exception from the server. > > While looking into to it, I found some difference between the > documentation of _unescape and the regex itself: > > Documentation: > # Unescape > # \xx where xx is a 2-digit hex number > # \y where y is one of ( ) \ * > > regex: > sub _unescape { > $_[0] =~ s/ > \\([\da-fA-F]{2}|.) > /.... > > well this regex matches any string with a \ and another character and > not only ( ) \ * for the next character > > \\([\da-fA-F]{2}|[()\\*]) > > seems to be more like the documentation. And this change fixed my problem.
At a first glance this sounds as if you have an illegal DN, as in DNs the + sign is used to separate the elements of a multi-part RDN. e.g. sn=Marschall+givenName=Peter,o=ADPM,c=DE If you want to use the + inside a value ,you need to escape it. e.g. cn=Peter\+Marschall,o=ADPM,c=DE What does your DN look like exactly * when used as DN? * when used in a filter? How does a dump of ldap_explode_dn() of your problematic DN look like? Best PEter -- Peter Marschall peter@adpm.de
  Fri Nov 23 16:35:32 2012 The RT System itself - Status changed from 'new' to 'open'
  Mon Nov 26 10:38:32 2012 peter [...] pjsc.de - Correspondence added
From: peter [...] pjsc.de
Hello Peter, I did recheck my sample and noticed that I missed the backslash in the filter. Sorry. The dn has a plus that is escaped. So the dn is ok. This is the search I start: my $mesg = $ldap->message('Net::LDAP::Search' => $arg); DB<15> x $arg 0 HASH(0x30ba4e64) 'attrs' => ARRAY(0x30bd019c) 0 'cn' 'base' => 'ou=memberlist,ou=ibmgroups,o=ibm.com' 'filter' => '(uniquemember=uid=9892\\+1897,c=us,ou=test,o=company.com)' 'scope' => 'one' in Net::LDAP::search the filter is created and the filter string parsed Net::LDAP::search(/usr/local/site_perl/aix/Net/LDAP.pm:450): 450: $f->parse($filter) 451: or return _error($ldap, $mesg, LDAP_PARAM_ERROR,"Bad filter"); DB<17> x $filter 0 '(uniquemember=uid=9892\\+1897,c=us,ou=test,o=company.com)' after parsing the filter the object looks like this 0 Net::LDAP::Filter=HASH(0x30ca4fc0) 'equalityMatch' => HASH(0x30c8a5fc) 'assertionValue' => 'uid=9892+1897,c=us,ou=test,o=company.com' 'attributeDesc' => 'uniquemember' The escaping backslash is gone. If I fix the _unescape subroutine as described in the initial post, the filter does include the backslash and everything works fine. Regards Peter
  Sat Dec 01 09:09:43 2012 peter [...] adpm.de - Correspondence added
Subject: Re: [rt.cpan.org #81380] is subroutine _unescape correct?
Date: Sat, 1 Dec 2012 15:17:06 +0100
To: bug-perl-ldap [...] rt.cpan.org
From: Peter Marschall <peter [...] adpm.de>
Hi, the fix is included in the freshly released perl-ldap 0.51. Thanks for your contribution. Peter -- Peter Marschall peter@adpm.de
  Sun Dec 02 07:55:54 2012 MARSCHAP [...] cpan.org - Status changed from 'open' to 'resolved'
  Sun Dec 02 07:55:54 2012 MARSCHAP [...] cpan.org - Fixed in 0.51 added