Giter Club home page Giter Club logo

spring-ldap's Introduction

Spring LDAP

Join the chat at https://gitter.im/spring-projects/spring-ldap

Build Status

Code of Conduct

This project adheres to the Contributor Covenant code of conduct. By participating, you are expected to uphold this code. Please report unacceptable behavior to [email protected].

INTRODUCTION

Spring LDAP is a library to simplify LDAP programming in Java, built on the same principles as Spring Jdbc.

The LdapTemplate class encapsulates all the plumbing work involved in traditional LDAP programming, such as creating, looping through NamingEnumerations, handling Exceptions and cleaning up resources. This leaves the programmer to handle the important stuff - where to find data (DNs and Filters) and what to do with it (map to and from domain objects, bind, modify, unbind, etc.), in the same way that JdbcTemplate relieves the programmer of all but the actual SQL and how the data maps to the domain model.

In addition to this, Spring LDAP provides Exception translation from NamingExceptions to an unchecked exception hierarchy, as well as several utilities for working with filters, LDAP paths and attributes.

For detailed information on the project, please refer to the reference documentation and javadocs. See the changelog for detailed information on changes in the latest version.

MAVEN USERS

All major releases of this library are available in the central Maven repository. The following components are available:

  • spring-ldap-core - the core Spring LDAP library
  • spring-ldap-core-tiger - the Spring LDAP Java 5 support library
  • spring-ldap-test - support classes that help LDAP with integration testing
  • spring-ldap-ldif-core - the Spring LDAP LDIF parsing library
  • spring-ldap-ldif-batch - the Spring Batch integration layer for the LDIF parsing library
  • spring-ldap-odm - The Object-Directory Mapping (ODM) framework

To include e.g. the spring-ldap-core component in your project, use the following dependency tag:

<dependency>
  <groupId>org.springframework.ldap</groupId>
  <artifactId>spring-ldap-core</artifactId>
  <version>2.3.2.RELEASE</version>
</dependency>

Milestone releases (such as release candidates) are available from the Spring framework milestone repo:

<repository>
  <id>spring-milestone</id>
  <name>Spring Portfolio Milestone Repository</name>
  <url>https://maven.springframework.org/milestone</url>
</repository>

Snapshot builds produced by the CI builds are available from the Spring framework snapshot repo:

<repository>
  <id>spring-milestone</id>
  <name>Spring Portfolio Milestone Repository</name>
  <url>https://maven.springframework.org/snapshot</url>
</repository>

In order to e.g. try out the latest build snapshot of the core module, include the repository above and use the following dependency tag:

<dependency>
  <groupId>org.springframework.ldap</groupId>
  <artifactId>spring-ldap-core</artifactId>
  <version>2.0.M1.CI-SNAPSHOT</version>
</dependency>

Note that while all milestone and snapshot builds have passed the (quite extensive) test suite, the artifacts here are obviously still work in progress. Feel free to use them for trying out new functionality and bug fixes for an upcoming version. Please report any problems or bugs in the issue tracker.

ADDITIONAL RESOURCES

spring-ldap's People

Contributors

marthursson avatar jzheaux avatar rwinch avatar nebhale avatar spring-builds avatar eddumelendez avatar kwin avatar marcusdacoregio avatar andrei-ivanov avatar wilkinsona avatar spring-operator avatar thomasdarimont avatar thepetrov avatar parkerm avatar jgrandja avatar jprinet avatar mfijas avatar antoine777 avatar dertobsch avatar perry2of5 avatar gitter-badger avatar bryant1410 avatar palfvin avatar orlandosso avatar mitch-mueller avatar kiliankrause avatar kimsaabyepedersen avatar jirkait avatar edysli avatar anidotnet avatar

Watchers

avatar Matias D. Fritz avatar avatar

spring-ldap's Issues

LDAP-131: How to Remove AttributeFrom the uniqueMember AttributeType

Original Reporter: anilkumarreddy
Environment: Windows98,ApachDS and JXPlorer
Version: 1.2
Migrated From: https://jira.spring.io//browse/LDAP-131
hi,can any one help me out to remove attribute from the uniqueMember field,the below shows the code what i have implemented..

ModificationItem[] modificationItem=new ModificationItem1;
modificationItem0=new ModificationItem(DirContextAdapter.REMOVE_ATTRIBUTE,
new BasicAttribute(“uniqueMember”,“uid=”+username+",ou=users,ou=system"));
return modificationItem;

when i have added the uniqueMember filed explicitly in JXPlorer i can able to remove using above code..if i add Attribute Using below code it is not deleting

ModificationItem[] modificationItem=new ModificationItem1;
modificationItem0=new ModificationItem(DirContextAdapter.ADD_ATTRIBUTE,
new BasicAttribute(“uniqueMember”,“uid=”+username+",ou=users,ou=system"));
return modificationItem;
Can any one please help me its very Urgent..

Thank u..

LDAP-81: Implement a Maven2 build system

Original Reporter: jasper.blues
Environment: Not Specified
Version: 1.2.1
Migrated From: https://jira.spring.io//browse/LDAP-81
- The top spring-ldap directory should be the parent
- spring-ldap-odm should be a separate artifact
- spring-ldap-tiger should be a separate artifact.

LDAP-113: Incorrect handling of PartialResultException in ldap.core.LdapTemplate

Original Reporter: jakub007
Environment: MS AD @ W2K3
Version: 1.2.1
Migrated From: https://jira.spring.io//browse/LDAP-113
Code in ldap.core.LdapTemplate is wrong, because while(results.hasMore())
is inside try/catch(PartialResultException), and exception breaks while loop,
but it shouldn’t. The try/catch(PartialResultException) should be located inside the while loop.
Like this:

public void search(SearchExecutor se, NameClassPairCallbackHandler handler,
DirContextProcessor processor) {
DirContext ctx = contextSource.getReadOnlyContext();

```
NamingEnumeration results = null;
RuntimeException ex = null;
try {
processor.preProcess(ctx);
results = se.executeSearch(ctx);
log.debug(“results are=”+results);

while(true) { try { if (!results.hasMore()) break; NameClassPair result = (NameClassPair) results.next(); log.debug(“result=”+result); log.debug(“result=”result.getName()", "+result.getClassName()); handler.handleNameClassPair(result); } catch (PartialResultException e) { if (ignorePartialResultException) { log.debug(“PartialResultException encountered and ignored: [”e.getResolvedName()"] "+ e.getRemainingName()); } else { ex = LdapUtils.convertLdapException(e); } continue; } catch (NullPointerException npe) { break; } } } catch (NameNotFoundException e) { // The base context was not found, which basically means // that the search did not return any results. Just clean up and // exit. // Note that this may present problems if a DirContextProcessor was // supplied – there’s no guarantee that the postProcess() operation // will go well after a NamingException has been thrown. It is // however quite possible that information will be available for // retrieval either way. e.printStackTrace(); } catch (javax.naming.NamingException e) { ex = LdapUtils.convertLdapException(e); } finally { try { processor.postProcess(ctx); } catch (javax.naming.NamingException e) { if (ex == null) { ex = LdapUtils.convertLdapException(e); } else { // We already had an exception from above and should ignore // this one. log.debug("Ignoring Exception from postProcess, " + “main exception thrown instead”, e); } } closeContextAndNamingEnumeration(ctx, results); // If we got an exception it should be thrown. if (ex != null) { throw ex; } }

}
```

see also: http://jira.springframework.org/browse/SEC-832

LDAP-99: Implementation and documentation of ContextSourceAndDataSourceTransactionManager seem contradictory

Original Reporter: hanswesterbeek
Environment: n/a
Version: 1.2.1
Migrated From: https://jira.spring.io//browse/LDAP-99

  1. Section 4.3 of the reference manual states:
  2. When performing a commit, the LDAP part of the operation will always be performed first, allowing both transactions to be rolled back should the LDAP commit fail.

The source thinks otherwise…

{code}
/*
\* @see org.springframework.jdbc.datasource.DataSourceTransactionManager#doCommit(org.springframework.transaction.support.DefaultTransactionStatus)
*/
protected void doCommit(DefaultTransactionStatus status)
throws TransactionException {

```
ContextSourceAndDataSourceTransactionObject actualTransactionObject = (ContextSourceAndDataSourceTransactionObject) status
.getTransaction();

try { super.doCommit(new DefaultTransactionStatus(actualTransactionObject .getDataSourceTransactionObject(), status .isNewTransaction(), status.isNewSynchronization(), status .isReadOnly(), status.isDebug(), status .getSuspendedResources())); } catch (TransactionException ex) { if (isRollbackOnCommitFailure()) { logger.debug(“Failed to commit db resource, rethrowing”, ex); // If we are to rollback on commit failure, just rethrow the // exception – this will cause a rollback to be performed on // both resources. throw ex; } else { logger .warn(“Failed to commit and resource is rollbackOnCommit not set -” + " proceeding to commit ldap resource."); } } ldapManagerDelegate.doCommit(new DefaultTransactionStatus( actualTransactionObject.getLdapTransactionObject(), status .isNewTransaction(), status.isNewSynchronization(), status.isReadOnly(), status.isDebug(), status .getSuspendedResources()));

}
```

{code}

LDAP-121: DefaultDirContextValidator uses ONELEVEL_SCOPE, validateDirContext() fails

Original Reporter: nate_moser
Environment: Not Specified
Version: 1.2.1
Migrated From: https://jira.spring.io//browse/LDAP-121
I found a small issue with org.springframework.ldap.pool.validation.DefaultDirContextValidator that will result in validateDirContext() failing for many/most LDAP implementations. The cause is that the root context search is being attempted with a search scope of SearchControls.ONELEVEL_SCOPE, the default scope when the scope isn’t specified. This may succeed for some LDAP implementations (I think it should for Domino), but will fail for e.g., Active Directory and SunONE.

The fix is to add
this.searchControls.setSearchScope(SearchControls.OBJECT_SCOPE);
to the constructor.

A workaround is to subclass DefaultDirContextValidator and make the same fix.

LDAP-62: Check JavaDocs

Original Reporter: marthursson
Environment: Not Specified
Version: Not Specified
Migrated From: https://jira.spring.io//browse/LDAP-62

LDAP-83: AbstractConnectionSource should ignore SUN_LDAP_POOLING_FLAG in base environment

Original Reporter: niallsmart
Environment: Not Specified
Version: 1.2-RC1
Migrated From: https://jira.spring.io//browse/LDAP-83
If I pass in a base environment to AbstractConnectionSource with the SUN_LDAP_POOLING_FLAG set to true then the AbstractConnectionSource incorrectly inherits this property from the base environment, even if I had called setPooled(false):

```
if (pooled) {
baseEnv.put(SUN_LDAP_POOLING_FLAG, “true”);
log.debug(“Using LDAP pooling.”);
} else {
log.debug(“Not using LDAP pooling”);
}

Hashtable env = new Hashtable(baseEnv);

```

This should be something more like:

```
Hashtable env = new Hashtable(baseEnv);

if (pooled) { env.put(SUN_LDAP_POOLING_FLAG, “true”); log.debug(“Using LDAP pooling.”); } else { env.remove(SUN_LDAP_POOLING_FLAG); log.debug(“Not using LDAP pooling”); }

```

This bug has security implications hence the high priority.

LDAP-176: AD Range Retrieval support

Original Reporter: mariuss
Environment: Not Specified
Version: 1.3.0
Migrated From: https://jira.spring.io//browse/LDAP-176
Active Directory has a hard limit on the number of values it returns for an attribute. If you want all the values you have to use “Incremental Retrieval of Multi-valued Properties”.

A utility class that takes care of all the details would be really useful.

References:
http://www.watersprings.org/pub/id/draft-kashi-incremental-00.txt
http://dunnry.com/blog/RangeRetrievalUsingSystemDirectoryServicesProtocols.aspx
http://msdn.microsoft.com/en-us/library/aa367017(VS.85).aspx
http://www.nntp.perl.org/group/perl.ldap/2005/02/msg1357.html

LDAP-123: java.lang.ClassCastException: org.springframework.ldap.transaction.compensating.manager.ContextSourceAndDataSourceTransactionManager$ContextSourceAndDataSourceTransactionObject thrown on inner transaction rollback

Original Reporter: jacqueline
Environment: Not Specified
Version: 1.2.1
Migrated From: https://jira.spring.io//browse/LDAP-123
Our project is using Spring-2.0.7 and spring-ldap-1.2.1.

When the ContextSourceAndDataSourceTransactionManager is used within another transaction manager, and they use the same data source, an exception occurs when the inner transaction is rolled back.

The stack trace is:

java.lang.ClassCastException: org.springframework.ldap.transaction.compensating.manager.ContextSourceAndDataSourceTransactionManager$ContextSourceAndDataSourceTransactionObject
at org.springframework.jdbc.datasource.DataSourceTransactionManager.doSetRollbackOnly(DataSourceTransactionManager.java:284)
at org.springframework.transaction.support.AbstractPlatformTransactionManager.processRollback(AbstractPlatformTransactionManager.java:761)
at org.springframework.transaction.support.AbstractPlatformTransactionManager.rollback(AbstractPlatformTransactionManager.java:730)

This seems to be because ContextSourceAndDataSourceTransactionManager does not override doSetRollbackOnly(). So when this is called, it uses the DataSourceTransactionManager’s implementation, which doesn’t know how to handle the ContextSourceAndDataSourceTransactionObject provided in status.getTransaction().

The following test case, using EasyMock, demonstrates the exception:

public void testNestedTransaction() throws Exception {

```
DataSource mockDataSource = createMock(DataSource.class);
expect(mockDataSource.getConnection()).andReturn(createMock(Connection.class));
replay(mockDataSource);

PlatformTransactionManager outerTxnManager = new DataSourceTransactionManager(mockDataSource); outerTxnManager.getTransaction(new DefaultTransactionDefinition()); ContextSourceAndDataSourceTransactionManager innerTxnManager = new ContextSourceAndDataSourceTransactionManager(); innerTxnManager.setContextSource(createMock(ContextSource.class)); innerTxnManager.setDataSource(mockDataSource); TransactionStatus innerTxnStatus = innerTxnManager.getTransaction(new DefaultTransactionDefinition()); innerTxnManager.rollback(innerTxnStatus);

```

}

LDAP-98: java.lang.VerifyError in class org.springframework.ldap.support.LdapUtils

Original Reporter: djura
Environment: Suse Linux 10.1, JDK 1.6_02
Version: 1.2.1
Migrated From: https://jira.spring.io//browse/LDAP-98
When trying to use Spring LDAP 1.2.1 with new Acegi namespace-based configuration, I get the following error:

ava.lang.VerifyError: (class: org/springframework/ldap/support/LdapUtils, method: convertLdapException signature: (Ljavax/naming/NamingException;)Lorg/springframework/ldap/NamingException;) Wrong return type in function
at org.springframework.ldap.core.support.AbstractContextSource.createContext(AbstractContextSource.java:235)
at org.springframework.security.ldap.DefaultSpringSecurityContextSource.getReadWriteContext(DefaultSpringSecurityContextSource.java:80)
at org.springframework.security.providers.ldap.authenticator.BindAuthenticator$BindWithSpecificDnContextSource.getReadOnlyContext(BindAuthenticator.java:134)
at org.springframework.ldap.core.LdapTemplate.executeReadOnly(LdapTemplate.java:770)

and so on.

Looking at sources, I can find the following possible reason: class org.springframework.ldap.core.support.AbstractContextSource imports javax.naming.NamingException, while class org.springframework.ldap.support.LdapUtils imports org.springframework.ldap.NamingException.
Now, in AbstractContextSource, method createContext() catches javax.naming.NamingException and rethrows it (line 235). But instead, method LdapUtils.convertLdapException(0 returns org.springframework.ldap.supportNamingException, thus leading to verification error.

Can somebody please verify this?

LDAP-84: Warning logs for anonymous ContextSource

Original Reporter: mlarchet
Environment: All OS
Version: 1.1.2
Migrated From: https://jira.spring.io//browse/LDAP-84
Using anonymous LdapContextSource cause WARN log entries.
In AbstractContextSource.java, lines 264 and 268, log.warn should be replaced by log.info or log.debug.

LDAP-143: Integration tests in article sample should not require running web server

Original Reporter: ulsa
Environment: Not Specified
Version: 1.3.0-RC1
Migrated From: https://jira.spring.io//browse/LDAP-143
The article sample has integration tests that require a running LDAP server. Currently, the tests themselves do not start one, so they pretty much require someone to have started the Jetty server first. The problem is that the jetty:run target will run the tests first! Chicken-and-egg problem. Using maven.test.skip for running the web server is not a good solution.

The solution is to use a TestContextSourceFactoryBean for the integration tests, just like everywhere else. Also, the LDAP server that is started by the web application should be running on a different port, so that the tests can be run whether the web server is up or not.

LDAP-130: DirContextAdapter getStringAttributes returns null

Original Reporter: relphie
Environment: Not Specified
Version: 1.2.1
Migrated From: https://jira.spring.io//browse/LDAP-130
from http://forum.springframework.org/showthread.php?t=59702

DirContextAdapter returns null when retrieving values for an attribute that does not exist. Instead of null, perhaps return an empty array. Or, Javadoc the potential null-value return.

LDAP-171: 1.3.0 class files doesn't match sources

Original Reporter: anders
Environment: Not Specified
Version: 1.3.0
Migrated From: https://jira.spring.io//browse/LDAP-171
While debugging spring-ldap configuration and stepping through spring-ldap code, I’ve noticed that the sources, as distributed, don’t match up when stepping through the code.

LDAP-155: DirContextAdapter creates DistinguishedName from DistinguishedName

Original Reporter: ulsa
Environment: Not Specified
Version: 1.3.0-RC1
Migrated From: https://jira.spring.io//browse/LDAP-155
DirContextAdapter always creates a DistinguishedName from the Name argument it receives, regardless if the argument already is a DistinguishedName. \
\
{code}
public DirContextAdapter(Attributes attrs, Name dn, Name base, String referralUrl) {
…
if (dn != null) {
this.dn = new DistinguishedName(dn);
}
…
if (base != null) {
this.base = new DistinguishedName(base);
}
{code}

In fact, we know that DefaultDirObjectfactory always calls DirContextAdapter with DistinguishedName for both base and dn:\
\
{code}
DirContextAdapter dirContextAdapter = new DirContextAdapter(attrs, new DistinguishedName(nameString),
new DistinguishedName(nameInNamespace), referralUrl);
{code}

Creating a DistinguishedName from a Name is a pretty expensive operation. Since all entries received from the LDAP server will be created this way, this could possibly have an impact on performance. It would be interesting to benchmark a large search before and after this has been fixed.

LDAP-152: New filters for searching based on a attribute being "present"

Original Reporter: jordanh
Environment: Not Specified
Version: 1.3.0-RC1
Migrated From: https://jira.spring.io//browse/LDAP-152
According to RFC2254 Ldap supports search filters based on an attribute being “present”. The filter is in the form of “(attr=*)”. Currently spring-ldap 1.2.1 does not support this filter in a clean way.

The filter can be achieved by using a LikeFilter as follows:

{code:title=Bar.java|borderStyle=solid}
LikeFilter likeFilter = new LikeFilter(“bar”, “*”));
{code}

However, this is hackish and is relying on the undocumented internal workings of the LikeFilter to split the value on the “_”, effectively removing the “_” and then appending on a “*” to achieve the “Like” behavior. Should the LikeFilter change in a future release users trying to get “present” behavior from the LikeFilter could be broken.

Therefore, I propose two new filter types called “PresentFilter” and a “NotPresentFilter”.

I will attach source code for these two classes.

LDAP-111: Multiple urls in contextSource

Original Reporter: mathiasberg
Environment: Not Specified
Version: 1.2.1
Migrated From: https://jira.spring.io//browse/LDAP-111
Setting multiple urls in ContextSource isnt setting the base for each url. It only sets on the last url.
…







….

Get this result in log.
…
…. Trying provider Urls: ldap://utv1.nu:389 ldap://test1.nu:389/dc=test,dc=nu
…

See forum thread http://forum.springframework.org/showthread.php?t=54889 for more detail.

LDAP-133: Compiling an extension of class DirContextAdapter with JDK 5 causes many "unchecked" warnings

Original Reporter: jfai
Environment: all
Version: 1.2.1
Migrated From: https://jira.spring.io//browse/LDAP-133
Extending org.springframework.ldap.core.DirContextAdapter causes many JDK 5 compiler warnings, although the methods in question are not overridden.

The methods in DirContextAdapter should be annotated with @SuppressWarnings(“unchecked”) or their signature should be fixed (this may not be possible due to interdependencies).

Example: public class PasswordPolicyDirContextAdapter extends DirContextAdapter {…} causes:

```
[javac] C:\jfworkspace\Kika\src\com\acesis\security\ldap\PasswordPolicyDirContextAdapter.java:27: warning: search(java.lang.String,java.lang.String,java.lang.Object[],javax.naming.directory.SearchControls) in org.springframework.ldap.core.DirContextAdapter implements search(java.lang.String,java.lang.String,java.lang.Object[],javax.naming.directory.SearchControls) in javax.naming.directory.DirContext; return type requires unchecked conversion
[javac] found : javax.naming.NamingEnumeration
[javac] required: javax.naming.NamingEnumeration
[javac] public class PasswordPolicyDirContextAdapter extends DirContextAdapter
[javac] ^
[javac] C:\jfworkspace\Kika\src\com\acesis\security\ldap\PasswordPolicyDirContextAdapter.java:27: warning: search(javax.naming.Name,java.lang.String,java.lang.Object[],javax.naming.directory.SearchControls) in org.springframework.ldap.core.DirContextAdapter implements search(javax.naming.Name,java.lang.String,java.lang.Object[],javax.naming.directory.SearchControls) in javax.naming.directory.DirContext; return type requires unchecked conversion
[javac] found : javax.naming.NamingEnumeration
[javac] required: javax.naming.NamingEnumeration
[javac] public class PasswordPolicyDirContextAdapter extends DirContextAdapter
[javac] ^
[javac] C:\jfworkspace\Kika\src\com\acesis\security\ldap\PasswordPolicyDirContextAdapter.java:27: warning: search(java.lang.String,java.lang.String,javax.naming.directory.SearchControls) in org.springframework.ldap.core.DirContextAdapter implements search(java.lang.String,java.lang.String,javax.naming.directory.SearchControls) in javax.naming.directory.DirContext; return type requires unchecked conversion
[javac] found : javax.naming.NamingEnumeration
[javac] required: javax.naming.NamingEnumeration
[javac] public class PasswordPolicyDirContextAdapter extends DirContextAdapter
[javac] ^
[javac] C:\jfworkspace\Kika\src\com\acesis\security\ldap\PasswordPolicyDirContextAdapter.java:27: warning: search(javax.naming.Name,java.lang.String,javax.naming.directory.SearchControls) in org.springframework.ldap.core.DirContextAdapter implements search(javax.naming.Name,java.lang.String,javax.naming.directory.SearchControls) in javax.naming.directory.DirContext; return type requires unchecked conversion
[javac] found : javax.naming.NamingEnumeration
[javac] required: javax.naming.NamingEnumeration
[javac] public class PasswordPolicyDirContextAdapter extends DirContextAdapter
[javac] ^
[javac] C:\jfworkspace\Kika\src\com\acesis\security\ldap\PasswordPolicyDirContextAdapter.java:27: warning: search(java.lang.String,javax.naming.directory.Attributes) in org.springframework.ldap.core.DirContextAdapter implements search(java.lang.String,javax.naming.directory.Attributes) in javax.naming.directory.DirContext; return type requires unchecked conversion
[javac] found : javax.naming.NamingEnumeration
[javac] required: javax.naming.NamingEnumeration
[javac] public class PasswordPolicyDirContextAdapter extends DirContextAdapter
[javac] ^
[javac] C:\jfworkspace\Kika\src\com\acesis\security\ldap\PasswordPolicyDirContextAdapter.java:27: warning: search(javax.naming.Name,javax.naming.directory.Attributes) in org.springframework.ldap.core.DirContextAdapter implements search(javax.naming.Name,javax.naming.directory.Attributes) in javax.naming.directory.DirContext; return type requires unchecked conversion
[javac] found : javax.naming.NamingEnumeration
[javac] required: javax.naming.NamingEnumeration
[javac] public class PasswordPolicyDirContextAdapter extends DirContextAdapter
[javac] ^
[javac] C:\jfworkspace\Kika\src\com\acesis\security\ldap\PasswordPolicyDirContextAdapter.java:27: warning: search(java.lang.String,javax.naming.directory.Attributes,java.lang.String[]) in org.springframework.ldap.core.DirContextAdapter implements search(java.lang.String,javax.naming.directory.Attributes,java.lang.String[]) in javax.naming.directory.DirContext; return type requires unchecked conversion
[javac] found : javax.naming.NamingEnumeration
[javac] required: javax.naming.NamingEnumeration
[javac] public class PasswordPolicyDirContextAdapter extends DirContextAdapter
[javac] ^
[javac] C:\jfworkspace\Kika\src\com\acesis\security\ldap\PasswordPolicyDirContextAdapter.java:27: warning: search(javax.naming.Name,javax.naming.directory.Attributes,java.lang.String[]) in org.springframework.ldap.core.DirContextAdapter implements search(javax.naming.Name,javax.naming.directory.Attributes,java.lang.String[]) in javax.naming.directory.DirContext; return type requires unchecked conversion
[javac] found : javax.naming.NamingEnumeration
[javac] required: javax.naming.NamingEnumeration
[javac] public class PasswordPolicyDirContextAdapter extends DirContextAdapter
[javac] ^
[javac] C:\jfworkspace\Kika\src\com\acesis\security\ldap\PasswordPolicyDirContextAdapter.java:27: warning: listBindings(java.lang.String) in org.springframework.ldap.core.DirContextAdapter implements listBindings(java.lang.String) in javax.naming.Context; return type requires unchecked conversion
[javac] found : javax.naming.NamingEnumeration
[javac] required: javax.naming.NamingEnumeration
[javac] public class PasswordPolicyDirContextAdapter extends DirContextAdapter
[javac] ^
[javac] C:\jfworkspace\Kika\src\com\acesis\security\ldap\PasswordPolicyDirContextAdapter.java:27: warning: listBindings(javax.naming.Name) in org.springframework.ldap.core.DirContextAdapter implements listBindings(javax.naming.Name) in javax.naming.Context; return type requires unchecked conversion
[javac] found : javax.naming.NamingEnumeration
[javac] required: javax.naming.NamingEnumeration
[javac] public class PasswordPolicyDirContextAdapter extends DirContextAdapter
[javac] ^
[javac] C:\jfworkspace\Kika\src\com\acesis\security\ldap\PasswordPolicyDirContextAdapter.java:27: warning: list(java.lang.String) in org.springframework.ldap.core.DirContextAdapter implements list(java.lang.String) in javax.naming.Context; return type requires unchecked conversion
[javac] found : javax.naming.NamingEnumeration
[javac] required: javax.naming.NamingEnumeration
[javac] public class PasswordPolicyDirContextAdapter extends DirContextAdapter
[javac] ^
[javac] C:\jfworkspace\Kika\src\com\acesis\security\ldap\PasswordPolicyDirContextAdapter.java:27: warning: list(javax.naming.Name) in org.springframework.ldap.core.DirContextAdapter implements list(javax.naming.Name) in javax.naming.Context; return type requires unchecked conversion
[javac] found : javax.naming.NamingEnumeration
[javac] required: javax.naming.NamingEnumeration
[javac] public class PasswordPolicyDirContextAdapter extends DirContextAdapter
[javac] ^
[javac] C:\jfworkspace\Kika\src\com\acesis\security\ldap\PasswordPolicyUserDetailsImpl.java:34: warning: [deprecation] getAttributes() in org.springframework.security.userdetails.ldap.LdapUserDetails has been deprecated
[javac] public class PasswordPolicyUserDetailsImpl extends LdapUserDetailsImpl {
[javac] ^
```

LDAP-28: Pre-encoded search filters

Original Reporter: jstepka
Environment: Not Specified
Version: Not Specified
Migrated From: https://jira.spring.io//browse/LDAP-28
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.

LDAP-147: HarcodedFilter and Editor

Original Reporter: mlarchet
Environment: Not Specified
Version: 1.3.0-RC1
Migrated From: https://jira.spring.io//browse/LDAP-147
The HardCoded Filter is a new improvement in Spring-LDAP 1.3.0 and I’m getting credits for it in the Javadoc, thank you.
However, simple configuration doesn’t work :

There’s no default property editor, so I have to write the following :

FilterEditor should be renamed to HardcodedFilterEditor to have things working out of the box, without registering any specific PropertyEditor.

LDAP-119: modifyAttributes produces invalid SchemaViolationException in a particular use case

Original Reporter: richrem
Environment: MacOSX, Apache Directory Server 1.0.2
Version: 1.2.1
Migrated From: https://jira.spring.io//browse/LDAP-119
This is most likely not related to any environment, but I have found the following issue with modifyAttributes:

Use case is a basic user/role relationship where we want to update the list of users that have been assigned to a role. A role has the following structure in our system, where values in are variable:

objectClass: groupOfUniqueNames
objectClass: top
cn:
uniqueMember:
uniqueMember:
…
description:

Since a groupOfUniqueNames must have at least one uniqueMember, the following use case pseudo code fails for us:

1) retrieve an existing role using the role DN
2) convert to a role domain object using a context mapper
3) update the list of uniqueMember (users) to a completely different set of users from the original using DirContextOperations.setAttributeValues(“uniqueMember”, newMembers)
4) call ldapTemplate.modifyAttributes
5) watch a completely (now explainable) bogus SchemaViolationException get thrown

The problem is that (I believe) the spring-ldap code deletes all the uniqueMember entries before adding the new ones, so the SchemaViolationException is thrown because you can’t have zero uniqueMembers.

Note: the SchemaViolationException is not thrown when at least one of the new users is the same as one that already exists for the role.

What (I believe) needs to happen is that more logic needs to be applied under the covers when the multi-attribute being modified is a required attribute, such that the zero value condition is not reached. A suggested approach might be to do set compares (old values vs new values) and add new (non-existing) ones first, then delete obsolete (existing, but not in new set) attribute values.

LDAP-158: filter classes do not encode the attribute; LDAP injection attack is possible

Original Reporter: tripleyew
Environment: Not Specified
Version: 1.2.1
Migrated From: https://jira.spring.io//browse/LDAP-158
I think I have found a general vulnerability in package org.springframework.ldap.filter

Basically the filter classes do not encode the attribute, only the value.
Assuming attribute names are not being validated elsewhere, an LDAP injection attack is possible.

Sample attack in the form of a JUnit test (may need refinement):

```
@Test
public void testEqualsFilterInjectionAttack() {
String expected = “(&)(foo=bar)”;
Filter filter = new EqualsFilter(“&)(foo”, “bar”);
assertEquals(expected, filter.encode());
}
```

where “(&)” means Absolute TRUE.

LDAP-112: org.springframework.ldap.core.DistinguishedName should respect RFC 4514

Original Reporter: bcurnow
Environment: Not Specified
Version: 1.2.1
Migrated From: https://jira.spring.io//browse/LDAP-112
Issue LDAP-91 was opened to address spaces in a DN

The solution provided does not match up with RFC 4514, according to section 2.1:

“The encodings of adjoining RelativeDistinguishedNames are separated by a comma (‘,’ U+002C) character.”

And then section 3:

“Implementations MAY recognize other DN string representations. However, as there is no requirement that alternative DN string representations be recognized (and, if so, how), implementations SHOULD only generate DN strings in accordance with Section 2 of this document.”

Also see all the examples in section 4.

Based on the RFC, spring-ldap should be able to parse DN string representations delimited by both command and space (or other whitespace characters, etc) but should only generate DN strings separated by commas.

While I agree that the version with spaces is more readable, the fact is that all LDAP servers are not required to recognize that as a DN string. Since spring-ldap writes the DN to the directory with spaces (e.g. uniquemember attributes using DNs) this needs to be changed.

I like the format method that was added for 1.2.2 which allows both COMPACT and NON_COMPACT representations, however, the default should be COMPACT.

LDAP-136: Setting Context.REFERRAL to 'follow' results in DN parse exception

Original Reporter: nate_moser
Environment: I’m using spring-ldap-1.2.1, issue should be OS and platform independent
Version: 1.2.1
Migrated From: https://jira.spring.io//browse/LDAP-136
In order to follow referrals, I’m using LdapContextSource with
env.put(Context.REFERRAL, “follow”);
ctx.setBaseEnvironmentProperties(env);

when a search includes results from following a referral, I get a exception

Caused by: org.springframework.ldap.BadLdapGrammarException: Failed to parse DN; nested exception is org.springframework.ldap.core.TokenMgrError: Lexical error at line 1, column 5. Encountered: “:” (58), after : ""
at org.springframework.ldap.core.DistinguishedName.parse(DistinguishedName.java:145)
at org.springframework.ldap.core.DistinguishedName.(DistinguishedName.java:100)
at org.springframework.ldap.core.DirContextAdapter.(DirContextAdapter.java:139)
at org.springframework.ldap.core.support.DefaultDirObjectFactory.getObjectInstance(DefaultDirObjectFactory.java:61)
at javax.naming.spi.DirectoryManager.createObjectFromFactories(Unknown Source)
at javax.naming.spi.DirectoryManager.getObjectInstance(Unknown Source)

Setting a breakpoint at DirContextAdapter shows that the DN in question is prefixed with the LDAP URL for the referred-to LDAP server. Apparently that’s how JNDI prefixes results returned from followed referrals, see
http://java.sun.com/products/jndi/tutorial/ldap/referral/follow.html

At Mattias’ suggestion, I subclassed DefaultDirObjectFactory and was able to work around the situation by stripping of the LDAP URL prefix. This could conceivably lead to namespace collision if a referred-to server has the same DIT structure as the original server (e.g., they both have a cn=nate,ou=users,dc=example,dc=com entry), but a situation the directory administrator should resolve.

I’ve tested this with searches Active Directory 2003, SunONE, and OpenLDAP servers with a single-hop referral to another server.

LDAP-70: NullPointerException when using manually created ldapTemplate when calling search if anonymousReadOnly=false

Original Reporter: mstoerze
Environment: Windows Client + OpenLDAP on SUSE Linux
Version: 1.2-RC1
Migrated From: https://jira.spring.io//browse/LDAP-70
Hello everybody,

we want to use Spring LDAP in a project and encountered the following problem:

We manually create the LDAP Template as follows:

private LdapTemplate crateLdapTemplate(final String userName, final String password) { LdapContextSource source = new LdapContextSource(); source.setUrl(url); source.setBase(base);

```
// TODO crash(NPE) if ‘false’ → Bug?
source.setAnonymousReadOnly(true);

// Credentials source.setUserName(“uid=” + userName + “,ou=people”); source.setPassword(password); // TODO crash(NPE) if ‘true’ → Bug? source.setCacheEnvironmentProperties(false); LdapTemplate ldapTemplate = new LdapTemplate(source); return ldapTemplate;

```

}

When setting either setCacheEnvironmentProperties to true or setAnonymousReadOnly to false, accessing LDAP fails with a NullPointerException. Access is as follows:

```
List < NjSecurityUser > users = ldapTemplate.search("", filter.encode(), userMapper);
```

Exception is as follows:

java.lang.NullPointerException
at org.springframework.ldap.support.AbstractContextSource.setupAuthenticatedEnvironment(AbstractContextSource.java:123)
at org.springframework.ldap.support.AbstractContextSource.getAuthenticatedEnv(AbstractContextSource.java:373)
at org.springframework.ldap.support.AbstractContextSource.getReadOnlyContext(AbstractContextSource.java:104)
at org.springframework.ldap.LdapTemplate.search(LdapTemplate.java:263)
at org.springframework.ldap.LdapTemplate.search(LdapTemplate.java:231)
at org.springframework.ldap.LdapTemplate.search(LdapTemplate.java:526)
at org.springframework.ldap.LdapTemplate.search(LdapTemplate.java:510)
at org.springframework.ldap.LdapTemplate.search(LdapTemplate.java:359)
at org.springframework.ldap.LdapTemplate.search(LdapTemplate.java:380)
at org.springframework.ldap.LdapTemplate.search(LdapTemplate.java:400)
at security.Authentification2SpringLdap.getUser(Authentification2SpringLdap.java:252)
at security.Authentication2SpringLDAPTest.testFindAllUsers(Authentication2SpringLDAPTest.java:45)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at junit.framework.TestCase.runTest(TestCase.java:154)
at junit.framework.TestCase.runBare(TestCase.java:127)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:128)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)

It seems that setting up an authentification source fails (it is not set explicitly but accessed and dereferenced although null). We do not want to use acgi, though – just plain user/password authentication.

Is there a misconception how we use / set up the ldap template or is this a bug in Spring LDAP? Borwsing the documentation and the issue database could not resolve the issue.

Thanks for any hints!

Best regards,
Max

LDAP-69: Upgrade guide - spellings

Original Reporter: davsclaus
Environment: Not Specified
Version: 1.2-RC1
Migrated From: https://jira.spring.io//browse/LDAP-69
Firstly thanks for this great framework.

Reading the .pdf upgrade guide

  1. missing and.

The transaction support is entirely new should not affect users of previous releases.

I think it should be “is entirely new and should not …”

  1. use of described instead of documented (typical scandinavian)

To sort it out, some major restructuring was needed, as
described in the following sections.

I think it should be “,as documented in the following sections”

  1. ctrl

(such as “Ctr+Shift-O” in Eclipse)

Should it not be “ctrl+shift+0”.

  1. courier font

The table in 1.1 could use courier font so its more code like.

LDAP-153: Spring Pooling does not support sorting ; Cannot call setRequestControls on a pooled context

Original Reporter: thomas.belot
Environment: *
Version: 1.3.0-RC1
Migrated From: https://jira.spring.io//browse/LDAP-153
When one use spring’s PoolingContextSource and Ldap sorting (through “SortControlDirContextProcessor”) or result limit (throuh “PagedResultsRequestControl”) this is causing a deadly UnsupportedOperationException(“Cannot call setRequestControls on a pooled context”).
Sun’s build in ‘supports’ this kind of controls (but see http://forum.springframework.org/showthread.php?p=213254 )

My guess joins Rasky’s explaination : Control state is kept on the server side wich means that sun’s impl is probably broken but at least request keep flowing.
Rasky’s idea of clearing the controls while returning connexion to the pool should be fine but how do we know the initial server state (if any : I don’t know the LDAProtocol very well)

Here is the stack trace
java.lang.UnsupportedOperationException: Cannot call setRequestControls on a pooled context
at org.springframework.ldap.pool.DelegatingLdapContex t.setRequestControls(DelegatingLdapContext.java:18 5)
at org.springframework.ldap.control.AbstractRequestCo ntrolDirContextProcessor.preProcess(AbstractReques tControlDirContextProcessor.java:83)
at org.springframework.ldap.core.support.AggregateDir ContextProcessor.preProcess(AggregateDirContextPro cessor.java:75)
at org.springframework.ldap.core.LdapTemplate.search( LdapTemplate.java:271)
at org.springframework.ldap.core.LdapTemplate.search( LdapTemplate.java:234)

LDAP-126: PagedResultsRequestControl should be non-critical

Original Reporter: mariuss
Environment: Not Specified
Version: 1.2.1
Migrated From: https://jira.spring.io//browse/LDAP-126
PagedResultsRequestControl controls are flagged as critical, ideally by default they should be non-critical.

See:
http://forum.springframework.org/showthread.php?t=59019

LDAP-168: Recursive Unbinds fail in transactional context

Original Reporter: kmbarlow
Environment: Spring LDAP – no environment dependencies.
Version: 1.3.0
Migrated From: https://jira.spring.io//browse/LDAP-168
The LdapTemplate object allows you to unbind an object and any nodes under it. The DefaultTempEntryRenamingStrategy generate the proper names, however, it gets called for the leaves first and then the higher level nodes. This is perfect with one exception… the performOperation() routine in the CompensatingTransactionOperationManager which creates the OperationExecutors for transactional operations, does not update the temporary DN of leaf DNs when a higher level node is unbound and renamed. Thus, when the commit is called, the leaf is still searched for under the original object name which has since been renamed and an EntryNotFound exception is thrown.

Forum discussion contains a simple solution which runs in N time – N should generally be small. I do not believe the issue applies to any other operations (rebinds are the only other operations which invoke the renaming logic and they do not delete entries).

LDAP-122: IllegalStateException: Cannot deactivate transaction synchronization - not active" thrown when when 'inner' transaction for LDAP context source fails to get a connection

Original Reporter: jacqueline
Environment: Not Specified
Version: 1.2.1
Migrated From: https://jira.spring.io//browse/LDAP-122
Our project is using Spring-2.0.7 and Spring-ldap-1.2.1.

We have a HibernateTransactionManager on an outer service, calling an inner service, which has wrapped an LDAP ContextSourceTransactionManager.

If a transaction is attempted when LDAP isn’t running, an exception occurs in Spring

java.lang.IllegalStateException: Cannot deactivate transaction synchronization – not active
at org.springframework.transaction.support.TransactionSynchronizationManager.clearSynchronization(TransactionSynchronizationManager.java:274)
at org.springframework.transaction.support.TransactionSynchronizationManager.clear(TransactionSynchronizationManager.java:412)
at org.springframework.transaction.support.AbstractPlatformTransactionManager.cleanupAfterCompletion(AbstractPlatformTransactionManager.java:916)
at org.springframework.transaction.support.AbstractPlatformTransactionManager.processRollback(AbstractPlatformTransactionManager.java:785)
at org.springframework.transaction.support.AbstractPlatformTransactionManager.rollback(AbstractPlatformTransactionManager.java:730)

This then stops any future Hibernate transactions.

I found an issue against Spring core, http://jira.springframework.org/browse/SPR-3438 , which I think is the same problem. This issue has been fixed in the extensions of AbstractPlatformTransactionManager in Spring core (eg HibernateTransactionManager, DataSourceTransactionManager).

The issue is resolved by catching Exception in the various implementations of doBegin(), and rethrowing a CannotCreateTransactionException, which is caught by AbstractPlatformTransactionManager.getTransaction(), which in turn resumes the outer transaction.

Should AbstractCompensatingTransactionManagerDelegate.doBegin() be doing the same?

In other words, should the fix applied to Spring core for this issue also be applied to spring-ldap?

To reproduce, the same test code in http://jira.springframework.org/browse/SPR-3438 can be used, but with the txMgrInner being a ContextSourceTransactionManager.

LDAP-117: Upgrade to Clover2

Original Reporter: npellow
Environment: Not Specified
Version: Not Specified
Migrated From: https://jira.spring.io//browse/LDAP-117
I’m upgrading projects at http://opensource.bamboo.atlassian.com/ to use Clover2.

[Spring LDAP |http://opensource.bamboo.atlassian.com/browse/SPRNG-LDAP/] is currently using an old version of Clover1.

I will attach a patch (changes should be minimal) to the spring-ldap/build.xml file to enable this.
You are also eligible for a Clover2 Open Source license if you don’t already have one within spring.

LDAP-172: Can't build 1.3.0 from sources

Original Reporter: anders
Environment: Not Specified
Version: 1.3.0
Migrated From: https://jira.spring.io//browse/LDAP-172
Following the instructions in build-instructions.txt, I get this error:

{code}
BUILD FAILED
C:\ThirdParty\main\spring-ldap\build.xml:19: The following error occurred while executing this line:
C:\ThirdParty\main\spring-ldap\itest-openldap-targets.xml:43: Cannot find C:\ThirdParty\main\spring-ldap/../common-build/itest-targe
ts.xml imported from C:\ThirdParty\main\spring-ldap\itest-openldap-targets.xml
{code}

common-build is not documented anywhere in the sources.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.