Home » Networking » Net_LDAP » Bug #6793
Problem with fetching schema?
Details
| Submitted | 2006-02-16 10:34 UTC |
|---|---|
| From | b dot hallinger at skyforcesystems dot de |
| Assigned | delatbabel |
| Status | Closed |
| Package | Net_LDAP |
| PHP Version | 4.4.2 |
| OS | Debian 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.