LDAP improvements for altBaseDN
Review and then apply patches to improve the altBaseDN feature. The altBaseDN lets users specify a second DN in LDAP to load data from. It currently only applies to authentication. This patch allows it to apply to user data. Notes about the patches:
LdapManager.java (Note: All changes in this file are standalone.)
Modified getContext() to respect alternateBaseDN
Modifed patch for to decode ldap url, so now patch actually works for users with spaces, etc.
Added method public String getUsersBaseDN(String username)
This method centralizes some of the changes made to LdapVCardProvider.java and LdapUserProvider.java
LdapVCardProvider.java (This change fixes problem 2 in post that originated )
Modified to respect alternateBaseDN (relies on changes to LdapManager.java)
Made signicifant changes all throughout to respect alternateBaseDN methods affected are
getUsers(int startIndex, int numResults)
findUsers(Set<String> fields, String query)
findUsers(Set<String> fields, String query, int startIndex, int numResults)
A few notes.
Ldap Groups still do not respect alternateBaseDN. I don't use them and had no way to test any changes so I left it alone.
If alternateBaseDN is used, I'm pretty sure Client Side sorting will fail. Again I don't use it so I couldn't prove this theory.
If a username exists in baseDN and alternateBaseDN
It will be listed twice
Both occurences are actually the same and come from baseDN
I'm reasonable sure but did not verify that it will only attempt to auth against the baseDN version.
It appears that a VCard lookup must suceed or a user is considered anonymous
When a user logs in to a client an IncompatibleClassChangeError exception is being thrown in PubSubModule.java at line 165. If that exception is not caught the user is immediately logged off the client.
Hi Matt, does CS have this at all? (does it support the altBaseDN concept) Or is it in the same boat as Openfire where only the user pieces support it, not groups?
At the same time as I'm doing this, I'm adding paged results support. Now, unfortunately, LDAP paged results aren't exactly what I think we thought they were. You can't apparently say "I want the results from this query starting at result 35 and ending at result 50". Instead, you just get a standard result to your query, with the ability to flip pages to get more results. So effectively what I'm implementing makes it so you can get more results. Suppose I should have pasted this part to the other JIRA issue, but hey. ;D
Noticed this was now "in-progress" Would be awesome to have this code be used in Clearspace too.
This is too large of a change to get into 3.1.0, pushing.
Note: the UserProvider will need to be updated since the UserProvider interface has changed. It would be best to diff and apply changes that way.