Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

findAll function in LdapRepository does not respect @Entry's base dn #446

Closed
harangozop opened this issue Oct 19, 2023 · 1 comment
Closed
Assignees
Labels
for: external-project For an external project and not something we can fix

Comments

@harangozop
Copy link

Expected behavior

When using an LdapRepository's findAll function it is expected to use the @Entry's base dn when searching through LDAP.

Actual behavior

The LdapRepository implementation does not use @Entry's base dn, instead it calls find all function with an empty base: https://github.com/spring-projects/spring-data-ldap/blob/main/src/main/java/org/springframework/data/ldap/repository/support/SimpleLdapRepository.java#L146C21-L146C21

Workaround

Of course, I could use the other findAll function, the one with the LdapQuery parameter: org.springframework.data.ldap.repository.support.SimpleLdapRepository#findAll(org.springframework.ldap.query.LdapQuery).
But I think it would be the better solution to use the base dn in the parameterless findAll as well.

Why is it important?

When handling multiple organization units with similar but not the same object classes in their user entries one query for under a specific org unit gives all the other org unit's users.

Reproduction

User.java

@Entry(
    base = "ou=people",
    objectClasses = {"top", "person", "inetOrgPerson"})
public class User implements Persistable<Name> {
  @Id
  private Name id;
  private @Attribute(name = "cn") String commonName;
}

UserRepository.java

@Repository
public interface UserRepository extends LdapRepository<User> {
}

OtherUser.java

@Entry(
    base = "ou=otherpeople",
    objectClasses = {"top", "person", "inetOrgPerson", "user"}) // notice the extra object class: user
public class OtherUser implements Persistable<Name> {
  @Id
  private Name id;
  private @Attribute(name = "cn") String commonName;
  // other extra attributes...
}

OtherUserRepository.java

@Repository
public interface OtherUserRepository extends LdapRepository<OtherUser> {
}

UserService.java

@Service
public class UserService {
  private final UserRepository userRepository;

  public UserService(UserRepository userRepository){
    this.userRepository = userRepository;
  }

  public List<UserRecord> findAll() { // that will give back all the "other" user entries as well as the simple user entries
    return userRepository
        .findAll()
        .stream()
        .map(u -> new UserRecord(u.getId().toString(), u.getCommonName()))
        .toList();
  }

}
@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged label Oct 19, 2023
@mp911de mp911de self-assigned this Oct 23, 2023
@mp911de
Copy link
Member

mp911de commented Nov 9, 2023

Thanks for reaching out. This is a known issue and needs to be controlled by Spring LDAP. They have a long-standing ticket for this, see pring-projects/spring-ldap#31.

Once Spring LDAP addresses that issue on their side, the baseDn will be considered.

@mp911de mp911de closed this as not planned Won't fix, can't repro, duplicate, stale Nov 9, 2023
@mp911de mp911de added for: external-project For an external project and not something we can fix and removed status: waiting-for-triage An issue we've not yet triaged labels Nov 9, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
for: external-project For an external project and not something we can fix
Projects
None yet
Development

No branches or pull requests

3 participants