The full webmail package will be hard to recreate from CVS. Jan always 
has to put a lot of effort into a release. I'd rely on a single patch 
then. Do you use the Kolab patch for Horde webmail? Adding another 
patch should not be too hard.

Thank you so much for doing this - it was going to be one of my first 
jobs this year! One question: I've had a look at the nightly builds, 
and can't figure out how to download the nightly equivalent snapshot 
of horde webmail edition for testing :(  Any pointer as to how I can 
recreate the tarball based upon the code in CVS?





Many thanks,



Mark.

Fixed in cvs.

Changes have been made in CVS for this ticket:

http://cvs.horde.org/diff.php/framework/Kolab_Server/lib/Horde/Kolab/Server/ldap.php?rt=horde&r1=1.6&r2=1.7&ty=u
http://cvs.horde.org/diff.php/framework/Kolab_Server/package.xml?rt=horde&r1=1.19&r2=1.20&ty=u
http://cvs.horde.org/diff.php/framework/Kolab_Server/test/Horde/Kolab/Server/ldapTest.php?rt=horde&r1=1.5&r2=1.6&ty=u
http://cvs.horde.org/diff.php/framework/Kolab_Server/test/Horde/Kolab/Server/testTest.php?rt=horde&r1=1.10&r2=1.11&ty=u

ping?

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.