Description: ------------ I updated from 0.6.6 to the CVS version because I was told this would fix an error in the method to add new attributes to entries in the LDAP directory. But when using the CVS version I can't even do simple searches which worked before. The CVS version seems to change the searchbase with no reason. Why is the CVS version labeled as 0.6.4 also it's supposed to be newer than 0.6.6?

just corrected a bad typo

My CVS checkout as of 2006/08/17 reports version 0.6.99, and i cant reproduce your error neither with php4 or php5. I checked out with the following command: `cvs -d :pserver:cvsread@cvs.php.net:/repository checkout pear/Net_LDAP` I additionally applied all patches that are provided at the bug tracker. Maybe this is a issue with php's ldap-extension?

test script: ============ <?php require_once 'Net/LDAP.php'; $dn = 'uid=userid, ou=bar, dc=foo, dc=de, o=Internet'; $password = 'password'; $params = array( 'host' => 'ldap.foo.bar', 'port' => 389, 'tls' => false, 'dn' => $dn, 'password' => $password, ); $connection =& Net_LDAP::connect($params); $connection->setLDAPVersion(3); $attributes = array('uid', 'sn', 'givenName', 'departmentNumber', 'memberOf'); $entry = $connection->getEntry($dn, $attributes); var_dump($entry->attributes()); ?> CVS-version (getting an empty result array) =========================================== [06/Sep/2006:08:11:00 +0200] conn=377 fd=68 slot=68 connection from xxx.xxx.xxx.xxx to xxx.xxx.xxx.xxx [06/Sep/2006:08:11:00 +0200] conn=377 op=0 BIND dn="" method=128 version=2 [06/Sep/2006:08:11:00 +0200] conn=377 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="" [06/Sep/2006:08:11:00 +0200] conn=377 op=1 BIND dn="uid=userid, ou=bar, dc=foo, dc=de, o=Internet" method=128 version=3 [06/Sep/2006:08:11:00 +0200] conn=377 op=1 RESULT err=0 tag=97 nentries=0 etime=0 dn="uid=userid, ou=bar, dc=foo, dc=de, o=Internet" [06/Sep/2006:08:11:00 +0200] conn=377 op=2 SRCH base="uid=userid, ou=bar, dc=foo, dc=de, o=Internet" scope=0 filter="(objectClass=*)" attrs="uid sn givenName departmentNumber memberOf" [06/Sep/2006:08:11:00 +0200] conn=377 op=2 RESULT err=0 tag=101 nentries=1 etime=0 [06/Sep/2006:08:11:00 +0200] conn=377 op=3 SRCH base="dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs="subschemaSubentry" [06/Sep/2006:08:11:00 +0200] conn=377 op=3 RESULT err=32 tag=101 nentries=0 etime=0 [06/Sep/2006:08:11:00 +0200] conn=377 op=3 RESULT err=32 tag=101 nentries=0 etime=0 [06/Sep/2006:08:11:00 +0200] conn=377 op=4 SRCH base="dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs="subschemaSubentry" [06/Sep/2006:08:11:00 +0200] conn=377 op=4 RESULT err=32 tag=101 nentries=0 etime=0 [06/Sep/2006:08:11:00 +0200] conn=377 op=4 RESULT err=32 tag=101 nentries=0 etime=0 [06/Sep/2006:08:11:00 +0200] conn=377 op=5 SRCH base="cn=Subschema" scope=0 filter="(objectClass=*)" attrs="attributeTypes dITContentRules dITStructureRules matchingRules matchingRuleUse nameForms objectClasses ldapSyntaxes" [06/Sep/2006:08:11:00 +0200] conn=377 op=5 RESULT err=32 tag=101 nentries=0 etime=0 [06/Sep/2006:08:11:00 +0200] conn=377 op=5 RESULT err=32 tag=101 nentries=0 etime=0 [06/Sep/2006:08:11:00 +0200] conn=377 op=6 UNBIND [06/Sep/2006:08:11:00 +0200] conn=377 op=6 fd=68 closed - U1 0.6.6 (getting the requested attributes' values) ================================================ [06/Sep/2006:08:12:29 +0200] conn=378 fd=68 slot=68 connection from xxx.xxx.xxx.xxx to xxx.xxx.xxx.xxx [06/Sep/2006:08:12:29 +0200] conn=378 op=0 BIND dn="uid=userid, ou=bar, dc=foo, dc=de, o=Internet" method=128 version=3 [06/Sep/2006:08:12:29 +0200] conn=378 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="uid=userid, ou=bar, dc=foo, dc=de, o=Internet" [06/Sep/2006:08:12:29 +0200] conn=378 op=1 SRCH base="uid=userid, ou=bar, dc=foo, dc=de, o=Internet" scope=0 filter="(objectClass=*)" attrs="uid sn givenName departmentNumber memberOf" [06/Sep/2006:08:12:29 +0200] conn=378 op=1 RESULT err=0 tag=101 nentries=1 etime=0 [06/Sep/2006:08:12:29 +0200] conn=378 op=2 UNBIND [06/Sep/2006:08:12:29 +0200] conn=378 op=2 fd=68 closed - U1 Why is Net_LDAP at first connecting with an empty dn (anonymous bind) and why is it connecting with protocol version 2? And why are there searches with the searchbase dc=example, dc=com ? Any hints? Sebastian

Your params look wrong. You need to set binddn and bindpw now with CVS version. Have a look at $_config definition in class Net_LDAP.

It still does not work. Actually using the old parameters should work as well because they get mapped to the new ones in the cvs version: function _setConfig($config) { // // Parameter check -- probably should raise an error here if config // is not an array. // if (! is_array($config)) { return; } foreach ($config as $k => $v) { if (isset($this->_config[$k])) { $this->_config[$k] = $v; } else { // map old (Net_LDAP) parms to new ones switch($k) { case "dn": $this->_config["binddn"] = $v; break; case "password": $this->_config["bindpw"] = $v; break; case "tls": $this->_config["starttls"] = $v; break; case "base": $this->_config["basedn"] = $v; break; } } }

My search works when using the native PHP LDAP functions directly. So everything is okay with the PHP installation and the LDAP directory server. It must be an issue with the Net_LDAP package generating these strange additional searches with the wrong searchbase. Can anyone help?

i think that maybe has something todo with php5. I cant reproduce the Problem with php 4.

(reopened, i thought that "feedback" would recolor the bug report)

Assigned to me, im on it

Regarding to Sebastian, he could only produce the bug under a certain machine and under a certain php5 version. Maybe this is a bug in this specific (he did not mention which exactly but i asked him already) php5 version. I still can't reproduce the bug.

his php-version is 5.0.4

Unfortunately i can not reproduce the bug under PHP 5.2.0. Maybe Sebastian should upgrade to PHP 5.2.0 and test again.

I recently tried to reprocude the probleme with PHP 5.2.0 on Debian Etch and PHP 5.1.6 on Fedora Core 6. Both times the problem did not occur and it was not a problem to retrieve the result. Also the schema was fetched without a problem. It seems as if Benedikt is right and this is an issue of PHP's LDAP extension or the PHP version itself.

I closed the bug, the problem is not caused by Net_LDAP. Thank you very much for your help improving Net_LDAP!