Search returns invalid JID (LDAP uids with spaces)

Hello,

Our corporate LDAP directory is set up so that users have a uid of ‘<firstname> <lastname>’ - so there is a space in the user’s login name.

I have set up an Openfire server at our site with LDAP support. I don’t have admin rights in the directory, just on the machine that has our Openfire server.

I have noticed some issues with some clients. I’ve done some checking, and the search results do not return valid JIDs. The space in the username is not escaped in the search results. As an example:

Name: Joe User

uid: joe user

jabber server: jabber.domain.com

JID: joe\20user@jabber.domain.com

search result: joe user@jabber.domain.com

Below is a real example of the interaction.

<iq type=“set” to=“search.jabber.lng.st.com” id=“ab0aa” >

<query xmlns=“jabber:iq:search”>

<x xmlns=“jabber:x:data” type=“submit” >

<field type=“hidden” var=“FORM_TYPE” >

<value>jabber:iq:search</value>

</field>

<field type=“text-single” var=“search” >

<value>kleven</value>

</field>

<field type=“boolean” var=“Username” >

<value>1</value>

</field>

<field type=“boolean” var=“Name” >

<value>1</value>

</field>

<field type=“boolean” var=“Email” >

<value>1</value>

</field>

</x>

</query>

</iq>

<iq from=“search.jabber.lng.st.com” type=“result” id=“ab0aa” to=“kleven\20bingham@jabber.lng.st.com/Psi” >

<query xmlns=“jabber:iq:search”>

<x xmlns=“jabber:x:data” type=“result” >

<reported>

<field label=“JID” var=“jid” />

<field label=“Username” var=“Username” />

<field label=“Name” var=“Name” />

<field label=“Email” var=“Email” />

</reported>

<item>

<field var=“jid” >

<value>kleven bingham@jabber.lng.st.com</value>

</field>

<field var=“Username” >

<value>kleven bingham</value>

</field>

<field var=“Name” >

<value>Kleven</value>

</field>

<field var=“Email” >

<value>kleven.bingham@domain.com</value>

</field>

</item>

<field type=“hidden” var=“FORM_TYPE” />

</x>

</query>

</iq>

Change the search service settings to not search usernames. That may help, may not. It is hard to tell since you are using non-standard characters in the username (spaces, special characters, etc). LDAP is a web protocol and should be structured as such. General rule that keeps you safe is if it can not be in an URL it should not be in LDAP.

The results returned by the search service do not vary based on which fields are searched. If there are hits for the search, the incorrect JID is returned.

JID escaping is supported throughout the rest of the Openfire server, and as best I can tell, it works well and works consistently.

As for using spaces in usernames, I think it is a bad idea. However, I have no control over this decision, since we have a directory with 10s of thousands of uids and it was put in place years ago. Technically, spaces are perfectly legal characters for uids in the standard LDAP schema. I was surpised to learn this myself, but given that they are legal characters, they should be supported by software that interacts with LDAP.

As a point of reference, XEP-0106 describes JID escaping. Since I don’t know how the search plugin works, I can only guess that the results I receive are built by the search plugin and that the search plugin does not implement XEP-0106 properly (or at all, I don’t know).

Hi Kleven,

What clients are you seeing this problem with? I checked in a change to the search plugin in June of '07 to unescape the node portion of the JID because there were a large number of users with clients that couldn’t handle an escaped JID properly. I don’t believe that the XEP-0055: Jabber Search specifies if the JID should be escaped in the search results so each client implements the spec in a slightly different way which can be tricky to handle. I could provide you with a tweaked version of the plugin that does not escape the JID but then you might run into problems with another group of users/clients.

Thanks,

Ryan

Hi Ryan,

Thank you for the response. Now I begin to see where the ambiguity of this situation is coming from.

So far, I’ve talked to a couple folks working on Psi, and they were of the opinion that escaping is largely a server activity and that the client should be pretty hands-off. I read through much of the discussion related to XEP-0106 and I realize that this was debated quite a bit.

I think the philosophy they are following is that anything that is declared as a JID (such as the jid field of the search results) should be a legal JID. If the client decides that they want to unescape it for ‘prettification’ reasons, that’s the decision of the client developers. The Psi developers seem to have the opinion that such ‘prettification’ is a potential source of confusion - but that’s just my take after a short conversation.

To some extent, I agree with their interpretation that anything that is called a JID should truly be a legal JID (i.e. escaped). Since I am somewhat new to the Jabber world, I don’t clearly understand whether implementing XEP-0106 means that it should be applied to all other XEP implementations by default, or whether other XEPs (i.e. XEP-0055) need to specifically reference XEP-0106 as required|optional.

The latter situation seems (to me) to add confusion since the end result is an appearance that XEP-0106 is not fully implemented. Is this a question that should be posed to the authors of XEP-0106 and XEP-0055?

After taking another quick look at XEP-0106, I noticed that there is a disco#info mechanism defined for XEP-0106. So, if I understand correctly, the search plugin should responed with a if the JIDs are actually escaped, correct?

I looked at the source code this morning and I understand how to modify it to get the desired results (except for the disco#info) but I’m not sure how to rebuild the plugin.

Thanks in advance for any help you can provide Ryan.

Kleven

Hi Kleven,

bkleven wrote:

The latter situation seems (to me) to add confusion since the end result is an appearance that XEP-0106 is not fully implemented. Is this a question that should be posed to the authors of XEP-0106 and XEP-0055?

XEP-0055 is considered a “historical” specification and hasn’t really been updated in over four years so I’m not sure how much feedback we’d get, but it certainly couldn’t hurt and it would be interesting hear what they would have to say.

After taking another quick look at XEP-0106, I noticed that there is a disco#info mechanism defined for XEP-0106. So, if I understand correctly, the search plugin should responed with a if the JIDs are actually escaped, correct?

Good question. Ideally I would think so but I’m not real sure if there are any clients that would know to change their behavior if that feature was added to the plugin because I’m not sure if they would know to look for it. I’d certainly be happy to look into this further once I get back into the office next week.

I looked at the source code this morning and I understand how to modify it to get the desired results (except for the disco#info) but I’m not sure how to rebuild the plugin.

Building an existing plugin is pretty easy. Take a look at this post of mine that provides some links on how to get started working with plugins.

I hope that helps,

Ryan

Thanks for your help Ryan.

I was able to recompile the plugin and my modified version works.

As for the question of initiating a discussion with the authors of the XEP, I’m not really sure how to go about that. Any suggestions?