spring-projects / spring-ldap Goto Github PK

Migrated from LDAP-51

Ulrik Sandberg(Migrated from LDAP-6) said:

The Name interface requires the compareTo() method to be implemented (strangely it does not extend the Comparable interface though). An implementation of this method should be easy enough.

Mattias Hellborg Arthursson(Migrated from LDAP-29) said:

A ContextSourceTransactionManager should be created to manage compensating transactions for LDAP. Initial efforts suggest that this should be quite possible without all that much work.

Ulrik Sandberg(Migrated from LDAP-34) said:

Both spring-ldap and sandbox have identical copies of itest-targets.xml, mainly because we shared common-build with other projects previously. Now we can move those to common-build and perhaps also get rid of some unnecessary overrides in the build.xml files.

Ulrik Sandberg(Migrated from LDAP-4) said:

The ExceptionTranslator could be improved to also automatically parse the error code and retrieve the corresponding readable message.

Ulrik Sandberg(Migrated from LDAP-39) said:

A popular request is that Spring LDAP should provide a simple authentication mechanism for those that don’t need the full power of Acegi Security. One approach that seems to work is this (taken from the forum http://forum.springframework.org/showthread.php?t=29063):

public boolean checkPassword(String login, String password) {
log.debug(“LdapServiceDao::checkPassword()”);

```
// Construction du DN
DistinguishedName dn = new DistinguishedName(“ou=People,dc=univ,dc=fr”);
dn.append(new DistinguishedName(getUserDn(login)));

// Connexion manuelle
LdapContextSource ctxSource = new LdapContextSource();
ctxSource.setUrl(url);
ctxSource.setUserName(dn.encode());
ctxSource.setPassword(password);
ctxSource.setPooled(false);
try {
ctxSource.afterPropertiesSet();
ctxSource.getReadWriteContext();
return true;
}
catch(Exception e) {
return false;
}
}
```

Mattias Hellborg Arthursson(Migrated from LDAP-43) said:

When using the current helper classes in the integration tests, the internal LDAP server is not re-populated between each test (the db should be cleaned and re-populated with the LDIF between each run). This can be done quite easily, as demonstrated in the corresponding files in the sandbox.

Create and Upload Maven POMs, Jars, Sources, and Javadocs for Spring LDAP 1.1.1

Jasper Blues(Migrated from LDAP-15) said:

DirContextAdapter.setAttributeValue(String, Object) and setAttributeValues(String, Object[]) add the attribute to DirContextAdapter.attrs or DirContextAdapter.updateAttrs (depending on updateMode) while setAttribute() does not.

Hence, calling setAttribute does not result in a ModificationItem.

Ulrik Sandberg(Migrated from LDAP-25) said:

Section 3.4, “A Complete Person DAO Class”, contains a dao without a finder method that takes a name, a company and a country. As it aspires to be a complete dao, it should probably have that finder.

Ulrik Sandberg(Migrated from LDAP-16) said:

There is a cycle between support and support.parser. It could probably be removed by generating the javacc parser code in the support package instead of support.parser.

Migrated from LDAP-35

Ulrik Sandberg(Migrated from LDAP-7) said:

Recursive delete should also be handled.

Create and upload Maven POMs for Spring LDAP 1.1.

Mattias Hellborg Arthursson(Migrated from LDAP-22) said:

Javadocs in DefaultDirObjectFactory should be cleaned up.

Ulrik Sandberg(Migrated from LDAP-2) said:

The RFC2253 specifies that a distinguished name should be able to have multi-valued RDNs separated by a ‘+’ sign, like “cn=Rod+sn=Johnson”, for example. There is a working parser written in C# here: http://www.codeproject.com/cs/internet/dnparser.asp

Jasper Blues(Migrated from LDAP-13) said:

Hello,
- We have a Person.java pojo containing a password property of type byte[]. The password property is set to and from the Sun Directory Server using a ContextMapper/ContextAssembler implementation.
- Problem: DirContextAdapter.getModificationsItems() always returns the password attribute as an updated attribute. This is due to byte arrays having a different hashcode despite identical content. Therefore b1[].equals(b2[]) returns false.

This could be a problem say if:
- Service subscriber 1 gets a handle to a Person pojo
- Service subscriber 2 gets a handle to a Person pojo, updates password attribute and saves.
- Service subscriber 1 updates “golden rating” attribute and saves. The new password is blown away.

Suggested Solution: Perhaps DirContextAdapter.isChanged() should use Arrays.equals(byte[], byte[]) for attributes of type byte[].

Best Regards,
Jasper

Michael Watson(Migrated from LDAP-47) said:

The last few lines of example 4.1 and 4.2 are incorrect. They are currently:

4.1
NameClassPairCallbackHandler handler =
ldapTemplate.new AttributesMapperCallbackHandler(new PersonAttributesMapper());

```
return ldapTemplate.search(executor, handler);
```

4.2
NameClassPairCallbackHandler handler =
ldapTemplate.new ContextMapperCallbackHandler(new PersonContextMapper());

```
return ldapTemplate.search(executor, handler);
```

They should be:

4.1
CollectingNameClassPairCallbackHandler handler =
ldapTemplate.new AttributesMapperCallbackHandler(new PersonAttributesMapper());

```
ldapTemplate.search(executor, handler);
return handler.getList();
```

4.2
CollectingNameClassPairCallbackHandler handler =
ldapTemplate.new ContextMapperCallbackHandler(new PersonContextMapper());

```
ldapTemplate.search(executor, handler);
return handler.getList();
```

Thanks to Ulrik Sandberg for the correct code.

Domagoj Madunic(Migrated from LDAP-30) said:

While trying to perform a simple search on InetOrgPersonObjects, via criteria uid=something

I encountered the following error:

org.acegisecurity.ldap.LdapDataAccessException: Failed to fetch user for username: dmadunic; nested exception is org.springframework.ldap.UncategorizedLdapExceptio n: Operation failed; nested exception is javax.naming.NamingException: problem generating object using object factory [Root exception is org.springframework.ldap.BadLdapGrammarException: RDN could not be parsed fully, remaining ‘c’]; remaining name ‘ou=croz,ou=Users’
org.springframework.ldap.UncategorizedLdapExceptio n: Operation failed; nested exception is javax.naming.NamingException: problem generating object using object factory [Root exception is org.springframework.ldap.BadLdapGrammarException: RDN could not be parsed fully, remaining ‘c’]; remaining name ‘ou=croz,ou=Users’
javax.naming.NamingException: problem generating object using object factory. Root exception is org.springframework.ldap.BadLdapGrammarException: RDN could not be parsed fully, remaining ‘c’
at org.springframework.ldap.support.LdapEncoder.nameD ecode(LdapEncoder.java:226)
at org.springframework.ldap.support.LdapRdnComponent. (LdapRdnComponent.java:69)
at org.springframework.ldap.support.DnParserImpl.attr ibuteTypeAndValue(DnParserImpl.java:112)
at org.springframework.ldap.support.DnParserImpl.rdn( DnParserImpl.java:62)
at org.springframework.ldap.support.DnParserImpl.dn(D nParserImpl.java:27)
at org.springframework.ldap.support.DistinguishedName .parse(DistinguishedName.java:130)
at org.springframework.ldap.support.DistinguishedName .(DistinguishedName.java:89)
at org.springframework.ldap.support.DirContextAdapter .(DirContextAdapter.java:131)
at org.springframework.ldap.support.DefaultDirObjectF actory.getObjectInstance(DefaultDirObjectFactory.j ava:56)
at javax.naming.spi.DirectoryManager.createObjectFrom Factories(DirectoryManager.java:228)
at javax.naming.spi.DirectoryManager.getObjectInstanc e(DirectoryManager.java:207)
at com.sun.jndi.ldap.LdapSearchEnumeration.createItem (LdapSearchEnumeration.java:118)
at com.sun.jndi.ldap.LdapNamingEnumeration.nextAux(Ld apNamingEnumeration.java:272)
at com.sun.jndi.ldap.LdapNamingEnumeration.nextImpl(L dapNamingEnumeration.java:252)
at com.sun.jndi.ldap.LdapNamingEnumeration.next(LdapN amingEnumeration.java:200)
at org.springframework.ldap.LdapTemplate.search(LdapT emplate.java:271)
at org.springframework.ldap.LdapTemplate.search(LdapT emplate.java:231)
at org.springframework.ldap.LdapTemplate.search(LdapT emplate.java:561)
at org.springframework.ldap.LdapTemplate.search(LdapT emplate.java:475)
at org.springframework.ldap.LdapTemplate.search(LdapT emplate.java:423)
at org.springframework.ldap.LdapTemplate.search(LdapT emplate.java:444)
…

This error occurs only with Ldap entires which have DN with national characters! When search is performed for entry with DN without national characters all goes well!

Jasper Blues(Migrated from LDAP-14) said:

Hello

We have a remote service utilizing Spring-Ldap. We’d like to be able to return exceptions to the service caller, however they’re not Serializable

Perhaps it is the wrapped NamingException that is not Serializable. My preference is for the exceptions to be serializable (perhaps there are other points of view), therefore I’d suggest to wrap the stack trace and message from NamingException and discard the non-Serializable part.

Regards,
Jasper

Justin Koke(Migrated from LDAP-50) said:

Hi Guys,

Here is the relevant issue that we have created in Crowd: http://jira.atlassian.com/browse/CWD-183

A quick summary:

If a group contains a ‘\’ we get the following exception:
javax.naming.NamingException: problem generating object using object factory [Root exception is org.springframework.ldap.BadLdapGrammarException: Failed to parse DN; nested exception is org.springframework.ldap.support.TokenMgrError: Lexical error at line 1, column 22. Encountered: “\” (92), after : ""]; remaining name ‘dc=ad,dc=atlassian,dc=com’
at com.sun.jndi.ldap.LdapSearchEnumeration.createItem(LdapSearchEnumeration.java:111)
at com.sun.jndi.ldap.LdapNamingEnumeration.nextAux(LdapNamingEnumeration.java:256)
at com.sun.jndi.ldap.LdapNamingEnumeration.nextImpl(LdapNamingEnumeration.java:236)
at com.sun.jndi.ldap.LdapNamingEnumeration.next(LdapNamingEnumeration.java:184)
at org.springframework.ldap.LdapTemplate.search(LdapTemplate.java:271)

If a group contains a ‘/’ we get this exception:
org.springframework.ldap.UncategorizedLdapException: Operation failed; nested exception is javax.naming.NamingException: [LDAP: error code 1 – 000020D6: SvcErr: DSID-031006CC, problem 5012 (DIR_ERROR), data 0]; remaining name ‘cn=Website Feedback/Support, ou=Groups, dc=ad, dc=atlassian, dc=com’
javax.naming.NamingException: [LDAP: error code 1 – 000020D6: SvcErr: DSID-031006CC, problem 5012 (DIR_ERROR), data 0
remaining name ‘cn=Website Feedback/Support, ou=Groups, dc=ad, dc=atlassian, dc=com’
at com.sun.jndi.ldap.LdapCtx.mapErrorCode(LdapCtx.java:3025)
at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2931)
at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2737)
at com.sun.jndi.ldap.LdapCtx.c_lookup(LdapCtx.java:993)
at com.sun.jndi.toolkit.ctx.ComponentContext.c_resolveIntermediate_nns(ComponentContext.java:152)
at com.sun.jndi.toolkit.ctx.AtomicContext.c_resolveIntermediate_nns(AtomicContext.java:342)
at com.sun.jndi.toolkit.ctx.ComponentContext.p_resolveIntermediate(ComponentContext.java:381)
at com.sun.jndi.toolkit.ctx.ComponentDirContext.p_search(ComponentDirContext.java:360)
at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:338)
at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:321)
at javax.naming.directory.InitialDirContext.search(InitialDirContext.java:248)
at org.springframework.ldap.LdapTemplate$4.executeSearch(LdapTemplate.java:227)

If you could shed any light onto this or point us in the right direction we will continue to investigate.

Cheers,
Justin

Mattias Hellborg Arthursson(Migrated from LDAP-23) said:

The javadocs of these methods need to be more descriptive.

Ulrik Sandberg(Migrated from LDAP-42) said:

There are a few nested classes in LdapTemplate that are used externally and should be promoted to top-level classes. These are AttributesMapperCallbackHandler and ContextMapperCallbackHandler.

Ulrik Sandberg(Migrated from LDAP-49) said:

We need an upgrade guide that explains the differences between earlier versions and 1.2.

Ulrik Sandberg(Migrated from LDAP-27) said:

There are no instructions for how to build the system from the buildable distribution, and what components you need to have installed.

Ulrik Sandberg(Migrated from LDAP-24) said:

The person sample currently uses Spring MVC for displaying a simple search result, from where the user can view or delete the entries, depending on the user’s privileges. The sample should be able to handle access groups, as it is the standard way of assigning privileges in LDAP. This will increase the number of search-result-view-edit flows in the applications. In order to simplify the handling of flows, the sample app should also be converted to Spring WebFlow 1.0. In doing so, we get re-usable flows that are described in readable XML.

Mayank Kumar(Migrated from LDAP-40) said:

Document – Single Page HTML reference.

In section 2.1, example 2.2

the line of code – “private class PersonAttributesMapper implements AttributesMapper() {”

should be changed to – “private class PersonAttributesMapper implements AttributesMapper {”

The braces after the AttributesMapper is incorrect.

Ulrik Sandberg(Migrated from LDAP-8) said:

TLS connections should be supported by Spring LDAP.

Mayank Kumar(Migrated from LDAP-41) said:

Document – Single Page HTML Reference

Example 2.2 in Section 2.1

Original Code -

Should be changed to

public List getAllPersons() {
return ldapTemplate.search("", “(objectclass=person)”, new PersonAttributesMapper());
}

The closing bracket for the ldapTemplate.search() method is missing.

Julio cesar(Migrated from LDAP-36) said:

Hi,

What changes do I have to make to the ldap-person example run in openLDAP instead of ApacheDS?

thank you,
Julio Cesar

Basically it should be sufficient to comment the line in src/main/webapp/WEB-INF/applicationContext.xml which imports apacheDsContext.xml and edit ldap.properties in the same directory to point to the appropriate server.

Some data is expected to be present in the target LDAP server, defined in src/main/java/setup_data.ldif.

Mattias Arthursson
Jayway AB (www.jayway.se)
Spring-LDAP project member

Yeah, I´ve done exactly that, but it didn´t worked. It gives me “Bad credential” error. My steps:
1. Comment import(apacheDS)
2. Populate openLDAP with base_data.ldif and setup_data.ldif
3. Replace user(cn=Manager) and password(secret).
4. Run…
5. “Bad Credentials”

Julio Cesar

Ah, right, you’ll need to change in applicationContext-acegi-security.xml to run against your OpenLDAP server as well (in ContextFactory definition). That’s nasty – it should be taken from the properties file. Might I ask you to post a Jira issue so we don’t lose track of that problem.

Mattias Arthursson
Jayway AB (www.jayway.se)

1. Spring-LDAP project member

Create and Upload Maven POMs, Jars, Sources, and Javadocs for Spring LDAP 1.1.2

adam goode(Migrated from LDAP-26) said:

Bug raised in response to following post on the spring ldap forum http://forum.springframework.org/showthread.php?t=32330

In an AD environment when using the Paged Results functionality after successfully retrieving and iterating over the returned results upto the set paged results size, the last call to results.hasMore() throws a PartialResultsException with a message of “Unprocessesed continuation reference”

This then causes the processor.postProcess(ctx) call to be missed meaning a cookie is never set to anything apart from null, meaning no more results can be returned. (this is all within the ldaptemplate::search(SearchExecutor se, NameClassPairCallbackHandler handler,DirContextProcessor processor) function)

Reply to original post on the forums indicates this is an issue with the way the exception handling works for that exception.

Same result is seen in both 1.1.1 and 1.1.2

Migrated from LDAP-3

Ulrik Sandberg(Migrated from LDAP-38) said:

The following ldapsearch gets all supported controls from the server:

% ldapsearch -s base “(objectclass=*)” supportedcontrol
supportedcontrol=2.16.840.1.113730.3.4.2
supportedcontrol=1.3.18.0.2.10.5
…

Perhaps it could be useful with a utility method that returned this information. In plain JNDI, the above ldapsearch is coded like this:

```
Hashtable env = new Hashtable();
env.put(Context.INITIAL_CONTEXT_FACTORY, “com.sun.jndi.ldap.LdapCtxFactory”);
env.put(Context.PROVIDER_URL, “ldap://localhost:389/”);

InitialDirContext ctx = new InitialDirContext(env);
Attributes attrs = ctx.getAttributes("", new String[] { “supportedcontrol” });

Attribute attr = attrs.get(“supportedcontrol”);
for (int i = 0; i < attr.size(); +i) {
System.out.println(attr.getID()“=”+attr.get(i));
}
```

Migrated from LDAP-32

Justen Stepka(Migrated from LDAP-37) said:

http://forum.springframework.org/showthread.php?p=96427#post96427

        Control[] requestControls = ldapContext.getRequestControls();
        Control newControl = createRequestControl();

```
    Control[] newControls = new Control[requestControls.length + 1];
    for (int i = 0; i < requestControls.length; i++) {
        newControls[i] = requestControls[i];
    }
```

new Control(int) needs to perform a null pointer check.

Fejer Melinda(Migrated from LDAP-17) said:

TLS connections should be supported by Spring LDAP.

Mattias Hellborg Arthursson(Migrated from LDAP-19) said:

When using paged results, the cookie needs to be supplied back to the client in order to be resupplied to subsequent operations. This means that the result list needs to be wrapped together with the cookie in a bean – we should provide a bean to do that, called e.g. PagedResult.

Michael Watson(Migrated from LDAP-48) said:

The code for the PersonAttributesMapper in example 2.2 is:

The () after the implements AttributesMapper causes a problem and should be removed.

It might also be worth mentioning at some point that this code causes all the attributes to be returned (not just the ones being mapped) and that you can use the setReturnedAttributes method on the SearchControls class to only return the attributes you need. Would be very helpful to LDAP noobs like myself.

Ulrik Sandberg(Migrated from LDAP-9) said:

Support should be added to automatically follow referrals in LdapTemplate, catching ReferralExceptions and ‘manually’ following the referral.

Jon Osborn(Migrated from LDAP-45) said:

org.springframework.ldap.support.LdapRdnComponent does not implement Serializable.

an ldap exception in spring web flow generates a ContinuationCreationException due to lack of serialization of this object. Any reason this cannot be serializable?

Mattias Hellborg Arthursson(Migrated from LDAP-20) said:

It is imperative that the actual byte array encapsulated in the PagedResultsCookie not be modified. It should be made immutable by copying the cookie in the constructor and returning a copy of the actual byte array in the getter.

Stefan Zoerner(Migrated from LDAP-44) said:

javadoc of method getLogicalOperator() of class BinaryLogicalFilter has mistakes in escaped characters. See patch for details.

Ulrik Sandberg(Migrated from LDAP-5) said:

It would be nice to have addAttributeValue/removeAttributeValue methods in DirContextAdapter to use when working with multi-value attributes.

Mattias Hellborg Arthursson(Migrated from LDAP-21) said:

getNameInNamespace() in DIrContextAdapter should return the full DN (including base), but this is not the case.

Migrated from LDAP-33

Ulrik Sandberg(Migrated from LDAP-12) said:

Currently, the only way to use a DirContextProcessor is to use the following method:

```
public void search(SearchExecutor se, NameClassPairCallbackHandler handler,
DirContextProcessor processor);
```

It would be nice with convenience methods that didn’t require a custom SearchExecutor.

Justen Stepka(Migrated from LDAP-28) said:

Currently all of the search filters require everything to be entered as a key/value pair. Add a filter that allows to the user to specify a filter, common when reading configuration files:

(objectClass=user)(!(objectClass=computer))

Attached is the implementation we are using for Crowd.

Mattias Hellborg Arthursson(Migrated from LDAP-18) said:

The userName property is confusing since it actually needs to contain the full dn of the user to authenticate. It should be renamed.

Vikash Trivedi(Migrated from LDAP-46) said:

DirContextAdapter.getModicationItems() calls collectModifications() to collect the modification items. The section handling multi-valued attributes uses CollectionUtils to return a new list that will contain a substraction of the old values from the new values, but the substraction doesnt handle case insensitivity thus resulting in a list of items that require to be added which already exist in the Directory Server with a different case and resulting in an ATTRIBUTE_ALREADY_EXISIT error. See below:
else {
// Collect all modifications to attribute individually (this also
// covers additions to a previously non-existant attribute).
Collection oldValues = new LinkedList();
Collection newValues = new LinkedList();

```
collectAttributeValues(oldValues, currentAttribute);
collectAttributeValues(newValues, changedAttr);
Collection myModifications = new LinkedList();

```