Tickets :: Comment on [#7694] LDAP objectclass lookups fail due to case sensitivity on objectclass match

* Your Email Address
* Spam protection	Enter the letters below: . ..__ .__ . .. . \|\/\|[__)[ __\| \|\|_/ \| \|\| [_./\|/\\|\| \
Comment	> Hi there, > > > > I've just upgraded one of our customer installations from HGWE 1.1 to > 1.2, and have come across a bug releated to case-sensitivity which > prevents users from even logging onto the new 1.2 edition. > > > > What happens is that _getObjectClasses() returns an associative > array of the objectclasses related to a particular DN, and the LDAP > server in question contains the specified objectclass but in > lower-case rather than camel-case format. This means that the > ldapsearch output looks something like this: > > > > > > dn: uid=foo,dc=some,dc=domain > > ... > > objectClass: kolabinetorgperson > > ... > > > > # search result > > search: 2 > > result: 0 Success > > > > # numResponses: 2 > > # numEntries: 1 > > > > > > The problem is related to this piece of code in > lib/Horde/Kolab/Server/ldap.php within the _determineType() method: > > > > if (!in_array('kolabInetOrgPerson', $oc)) { > > ... > > } > > > > It should be reasonably obvious that the reason the login fails is > because the associative array stores the value returned from LDAP in > lower case, while the current code is looking for the camel-case > version. Temporarily changing the code so that it matches on > 'kolabinetorgperson', all in lower-case, allows the login to proceed > correctly. > > > > AFAICT objectclasses are by RFC definition aaply case-insensitive > matching, so it may be that the simplest fix is to force all > objectclasses for a given DN to lower case before putting them in the > associative array, and then performing all comparisons in the code > with lower case names. However, I am not sure whether or not this > will have any further unexpected side-effects. > > > > > > ATB, > > > > Mark. > >
Attachment
Watch this ticket

Saved Queries