PEAR is archived and read-only

This mirror preserves historical PEAR package releases and metadata so existing references remain available.

Home » Networking » Net_LDAP » Bug #6793

Problem with fetching schema?

Details

Submitted2006-02-16 10:34 UTC
Fromb dot hallinger at skyforcesystems dot de
Assigneddelatbabel
StatusClosed
PackageNet_LDAP
PHP Version4.4.2
OSDebian Linux
Roadmaps(Not assigned)

Comments

[2006-02-16 10:34 UTC] b dot hallinger at skyforcesystems dot de

Description:
------------
I think there is a problem with fetching an LDAP-Schema.
The problem occoures in conjunction with the utf8Decode() method supplied by the LDAP class. First i thought it is a problem there, but Attributes (DIR_STRING) get never decoded, because the Schema remains empty.
The LDAP-Server is a LDAPv3 Siemens DirX.

It would be nice to see if others also have problems with this, or if this is a local problem here, but maybe it is related to the following:

I found a "maybe-bug" in LDAP.php, near line 932:
if (is_null($dn)) {
$dn = 'cn=Subschema';
}

The same condition is tested in the if-block above, so $dn gets overwritten.

a solution to this is replacing this block with:
if (!is_null($dn)) {
$dn = 'cn=Subschema';
}

I don't know if this is related to this bug, but solving the if doesn't make the schema fetch correctly here.
Maybe this is also related to Bug #4275

Test script:
---------------
//connects made above, a successfull search was performed
$attr = $ldap_search->get_value($attribute_name,'alloptions');
echo $attr[0];
$attr_decoded = $this->_ldap->utf8Decode($attr);
echo $attr_decoded[0];

Expected result:
----------------
If i call this with the Attribute "München", wich is stored in UTF-8 in the directory, the attribute should be decoded properly:

München
München

Actual result:
--------------
The actual result is, that the attribute gets not decoded:

München
München

[2006-02-16 11:32 UTC] b dot hallinger at skyforcesystems dot de

Short addition to my post above:
if the "if" block gets corrected, then a Net_LDAP_ERROR is generated, the message is:
"Net_LDAP_Error: Could not fetch Subschema entry"

[2006-02-16 12:11 UTC] b dot hallinger at skyforcesystems dot de

:/ I found out that the Problem above is partially a configuration problem at my site.
The problem was somewhere else, but i'm on it.

I think i can submit a patch soon.

[2006-02-16 12:33 UTC] b dot hallinger at skyforcesystems dot de

Okay, it was a simple uppercase/lowercase mix.
Here is the patch:

--- LDAP.php 2005-03-01 13:27:36.000000000 +0100
+++ LDAP.php_fixed 2006-02-16 13:31:34.983151576 +0100
@@ -921,9 +921,9 @@

if (is_null($dn)) {
// get the subschema entry via root dse
- $dse = $this->rootDSE(array('subschemaSubentry'));
+ $dse = $this->rootDSE(array('subSchemaSubentry'));
if (false == Net_LDAP::isError($dse)) {
- $base = $dse->getValue('subschemaSubentry', 'single');
+ $base = $dse->getValue('subSchemaSubentry', 'single');
if (!Net_LDAP::isError($base)) {
$dn = $base;
}

[2006-02-16 12:41 UTC] b dot hallinger at skyforcesystems dot de

(reopened the bug so maintainers can include the patch in the CVS version)

[2006-02-24 03:15 UTC] delatbabel at php dot net

This is a bug in Siemens DirX.

RFC 2251 section 3.2.1 defines the required entry as "subschemaSubentry" and not "subSchemaSubentry". See http://rfc.net/rfc2251.html#s3.2.1.

I will add a patch that searches for "subSchemaSubentry" as well to work-around such buggy LDAP servers.

You should also report this bug to your LDAP server vendor (Siemens) and request a fix.

[2006-02-24 03:15 UTC] delatbabel at php dot net

Assign to me.

[2006-02-24 03:42 UTC] delatbabel at php dot net

This bug has been fixed in CVS.

If this was a documentation problem, the fix will appear on pear.php.net by the end of next Sunday (CET).

If this was a problem with the pear.php.net website, the change should be live shortly.

Otherwise, the fix will appear in the package's next release.

Thank you for the report and for helping us make PEAR better.