| CC: | <Koen.Bailleul [...] ing.be>, <luc.duerinckx [...] ing.be>, <Rik.Bobbaers [...] ing.be> |
| Subject: | Bug in perl module Net::LDAP::Control::Paged when used with Redhat Directory Server of fedora 389 directory server |
| Date: | Fri, 6 Dec 2013 08:38:55 +0100 |
| To: | <bug-perl-ldap [...] rt.cpan.org> |
| From: | <david.deborre [...] ing.be> |
Hello,
We are testing the paging functionality on Redhat Directory Server and the fedora 389 directory server using the perl module Net::LDAP and have encountered a bug.
When we run the following code:
use Net::LDAP;
use Net::LDAP::Control::Paged;
use Net::LDAP::Constant qw( LDAP_CONTROL_PAGED );
use Net::LDAP::LDIF
# Input values
$LdapServer="ldap://<system>:<port>";
$user="cn=Directory Manager";
$passwd="xxxx";
## Main
$ldap = Net::LDAP->new($LdapServer) or die "##ERROR## connecting to LDAP server $LdapServer .\n";
$mesg = $ldap->bind ( dn => $user, password =>$passwd);
if ( $mesg->code()) {
die ("##ERROR##", $mesg->code(),"\n","error name: ",$mesg->error_name(),"\n", "error text: ",$mesg->error_text(),"\n");
}
# Set number of entry to return per page
$page = Net::LDAP::Control::Paged->new( size => 1 );
@args = ( base => "ou=xxxx,ou=xx,o=xxx",
scope => "subtree",
filter => "(objectclass=*)",
# filter => "(&(objectclass=posixaccount) (userpassword=*))",
callback => \&process_entry, # Call this sub for each entry
control => [ $page ],
);
#
my $cookie;
while (1) {
# Perform search
my $mesg = $ldap->search( @args );
print "DDB debug0.1\n";
# successful search returns 0
if ($mesg->code){
exit print "LDAP Search Failed $?\n";
}
# Net::LDAP::LDIF->new( \*STDOUT,"w" )->write( $mesg->entries );
## # Only continue on LDAP_SUCCESS
## $mesg->code and last;
print "DDB debug0.2\n";
# Get cookie from paged control
my($resp) = $mesg->control( LDAP_CONTROL_PAGED ) or last;
print "DDB debug0.3 \n";
print "DDB debug, print ldap controle: $resp\n";
$cookie = $resp->cookie or last;
print "DDB debug0.4 \n";
print "DDB debug0.5 $cookie \n";
# Set cookie in paged control
$page->cookie($cookie);
}
if ($cookie) {
# We had an abnormal exit, so let the server know we do not want any more
$page->cookie($cookie);
$page->size(0);
$ldap->search( @args );
print "DDB debug2.\n";
}
print "DDB debug 3.\n";
sub process_entry {
my ( $msg, $result ) = @_;
return if ( ! defined($result) );
$result->dump( );
print "\n";
}
this is the standaert code from CPAN for "Single paging", nothing special.
what happens is that after a first page the programm stops, this means that the cookie is not received from the LDAP server the problem is in line:
$cookie = $resp->cookie or last;
the loop is exited because the coockie is not received and this the following pages are not displayed and the paging does not work.
We first thought the problem was with the Redhat Directory Server or the 389 Directory Server and opened a support call with Redhat for this issue, we got the following result:
Hi,
Engineering has confirmed this issue is not a bug in RHDS, we could open a bug against perl-LDAP to fix the sample code for paged results.
Here is the complete update from Engineering:
-------------------------------
RHDS is sending back valid values. You can run the script like this:
my $ldap = Net::LDAP->new($LdapServer, debug => 8) or die "##ERROR## connecting to LDAP server $LdapServer .\n";
You will see output like this:
Net::LDAP=HASH(0x15dcf30) received:
0000 50: SEQUENCE {
0002 1: INTEGER = 2
0005 7: [APPLICATION 5] {
0007 1: ENUM = 0
000A 0: STRING = ''
000C 0: STRING = ''
000E : }
000E 36: [CONTEXT 0] {
0010 34: SEQUENCE {
0012 22: STRING = '1.2.840.113556.1.4.319'
002A 8: STRING
002C : 30 06 02 01 09 04 01 30 __ __ __ __ __ __ __ __ 0......0
0034 : }
0034 : }
0034 : }
The paged result response value contains the size and the cookie (starting at 002C):
30 - start sequence
06 - 6 bytes follow
02 - integer tag (size tag)
01 - length of integer (size length)
09 - value of integer (this is the $resp size)
04 - octet string tag (cookie tag)
01 - string length (cookie length)
30 - string value (cookie value - e.g. the string "0")
The problem is this line:
$cookie = $resp->cookie or last;
Note that in perl, the string "0" is automatically converted to a decimal 0 for the boolean test using the "or". Thus, the test fails because 0 is also the perl value for FALSE.
Looking at the RFC http://tools.ietf.org/html/rfc2696
3. Client-Server Interaction
The cookie (from the server) MUST be set to an
empty value if there are no more entries to return (i.e., the page of
search results returned was the last), or, if there are more entries
to return, to an octet string of the server's choosing,used to resume
the search.
Note that the result sent by the server for the cookie value is "0", which is NOT an empty value. The better test in perl would be something like this:
$cookie = $resp->cookie;
if (defined($cookie) && length($cookie)) {
print "DDB debug0.4 \n";
print "DDB debug0.5 $cookie \n";
} else {
last;
}
# Set cookie in paged control
$page->cookie($cookie);
I'm closing this issue as NOTABUG. Please feel free to open a bug against the perl-LDAP component to fix the example Simple Paged results code.
------------------------------------------
Please let us know if you have further queries.
Kind Regards,
Najmuddin.
Apparently this issue is in the perl module not in the directory server. Could you please have a look and if possible resolve the issue in the code.
We would very much like to use the perl module for using the paging on the directory server, thanks for the help!
Met vriendelijke groeten - Bien cordiallement - Kind regards,
David De Borre
ING Belgium - Ops & IT Banking
ITS INF OSS ESM
Security System Engineering
Sint-Michielswarande 60 (CSM +2 Napoli 27)
1040 Brussels, Belgium
** +32 (0)2 (73)83876 F: +32 (0)2 (73)8.32.56
Email: <mailto:david.deborre@ing.be>
Team mailbox: <mailto:BE-OIB TO BoKS Project<mailto:BE-OIB%20TO%20BoKS%20Project>>
HPSC queue: "L3 OIB/ISS/BE/SEC/ESM"
-----------------------------------------------------------------
ATTENTION:
This e-mail is intended for the exclusive use of the
recipient(s). This e-mail and its attachments, if any, contain
confidential information and/or information protected by
intellectual property rights or other rights. This e-mail does
not constitute any commitment for ING Belgium except when
expressly otherwise agreed in a written agreement between the
intended recipient and ING Belgium.
If you receive this message by mistake, please, notify the sender
with the "reply" option and delete immediately this e-mail from
your system, and destroy all copies of it. You may not, directly
or indirectly, use this e-mail or any part of it if you are not
the intended recipient.
Messages and attachments are scanned for all viruses known. If
this message contains password-protected attachments, the files
have NOT been scanned for viruses by the ING mail domain. Always
scan attachments before opening them.
-----------------------------------------------------------------
ING Belgium SA/NV - Bank/Lender - Avenue Marnix 24, B-1000
Brussels, Belgium - Brussels RPM/RPR - VAT BE 0403.200.393 -
BIC (SWIFT) : BBRUBEBB - Account: 310-9156027-89 (IBAN BE45 3109
1560 2789).
An insurance broker, registered with the Financial Services and
Markets Authority under the code number 12381A.
ING Belgique SA - Banque/Preteur, Avenue Marnix 24, B-1000
Bruxelles - RPM Bruxelles - TVA BE 0403 200 393 - BIC (SWIFT) :
BBRUBEBB - Compte: 310-9156027-89 (IBAN: BE45 3109 1560 2789).
Courtier d'assurances inscrit a la FSMA sous le numero 12381A.
ING Belgie NV - Bank/Kredietgever - Marnixlaan 24, B-1000 Brussel
- RPR Brussel - BTW BE 0403.200.393 - BIC (SWIFT) : BBRUBEBB -
Rekening: 310-9156027-89 (IBAN: BE45 3109 1560 2789).
Verzekeringsmakelaar ingeschreven bij de FSMA onder het nr.
12381A.
-----------------------------------------------------------------
Message body is not shown because it is too large.