We're updating the issue view to help you get more done. 

LDAP group handler should escape dollar signs in values when used with regexps

Description

From forums:

eGroupware creates the postalAddress and homePostalAddress attribute compositing the various street, city, zip, etc.. using some dollar signs ($).

Openfire works without a problem, and I and the other users can login and send messages and such. However, when I tried to configure some transports to ICQ and MSN, the transports didn't work and I kept getting in the debug log the following entries:

2008.04.01 21:45:10 LdapVCardProvider: Getting mapped vcard for rob.mau
2008.04.01 21:45:10 Exception while processing packet: java.lang.IllegalArgumentException: Illegal group reference

I'm no java programmer, but I've searched google for "Illegal group reference", and the first entry is this: http://cephas.net/blog/2006/02/09/javalangillegalargumentexception-illegal-group-reference-replaceall-and-dollar-signs/

There the blog's author explains that when using the replaceAll method of the String object, the first argument is considered a regular expression, and any occurrence of $ in the second parameter is taken as a backreference to a parenthesis group inside the regular expression in the first. Too bad this isn't the case, and we get the "Illegal group reference".

I suspected that in the mapping of LDAP attributes to a user vcard there's a String.replaceAll that's used, and that when it tries to replace postalAddress it get confused by the dollar sign before the ZIP code.

As a test, I removed the $ signs in my user record, and I was able to use the transport without a problem

So I'd say that LdapVCardProvider (don't know if it's local to the IM Transport plugin or a system function of Openfire) does not escapes correctly the $ signs it may find in the LDAP records that it tries to map to a vcard for the user logging in the Transport.
For egroupware there's a "best fix" to NOT use "postalAddress" and "homePostalAddress" as "Home street address" and "Business street address" in the user profile vCard definition: this way there are no $ signs in the vcard mapping and no errors.

But this problem could bite for every LDAP field that gets mapped in the user vcard if in some field you have a $ sign followed by a number. The fix should be to escape every dollarsign with a backslash (and this probably has been already done for the core, since it works even with the addresses full of dollarsigns)

Environment

None

Acceptance Test - Entry

None

Assignee

Daniel Henninger

Reporter

Daniel Henninger

Labels

None

Expected Effort

None

Ignite Forum URL

None

Components

Fix versions

Priority

Major
Configure