From: russ at bluecows dot com Operating system: Linux PHP version: Irrelevant Package: LDAP related Bug Type: Bug Bug description:ldap_search() fails on base64-encoded entries
Description: ------------ When using the ldap_search() function to query data from an LDAP database, it would appear that base64-encoded attributes are not decoded before running the search pattern against them. Based on the code snippets below, if the first search is run, no results are returned, even if a DN in the search tree has a postalAddress attribute which matches the given search string. If the second search is run, results are returned, indicating the search can check to see if the attribute exists at all, but the text-based search string is being checked against a base64-encoded attribute. It would appear that ldap_get_entries() decodes base64-encoded attributes, because the output of $entries, when it is not NULL, will show postalAddress as text. In order for ldap_search() to work properly, it should decode base64-encoded attributes before attempting to run the search against them. Test script: --------------- Failed test: $search = ldap_search( $ldapHandle, $ldapBaseDn, "(postaladdress=*165 Main*)" ); $entries = ldap_get_entries( $ldapHandle, $search ); Successful test: $search = ldap_search( $ldapHandle, $ldapBaseDn, "(postaladdress=*)" ); $entries = ldap_get_entries( $ldapHandle, $search ); Expected result: ---------------- In the failed test example, I would expect $entries to contain a list of LDAP DNs and associated attributes where the postalAddress attribute matches the search parameter. Currently, it does not. Searches against non-base64-encoded attributes such as mail or telephoneNumber work as expected. Actual result: -------------- When the failed test example is run, $entries is empty because no matches are returned from the ldap_search(). -- Edit bug report at https://bugs.php.net/bug.php?id=64392&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=64392&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=64392&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=64392&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=64392&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=64392&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=64392&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=64392&r=needscript Try newer version: https://bugs.php.net/fix.php?id=64392&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=64392&r=support Expected behavior: https://bugs.php.net/fix.php?id=64392&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=64392&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=64392&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=64392&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64392&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=64392&r=dst IIS Stability: https://bugs.php.net/fix.php?id=64392&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=64392&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=64392&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=64392&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=64392&r=mysqlcfg
