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

Operational Attributes support should not require read-only attributes #446

Closed
krzysztofmarzec3 opened this issue Mar 13, 2017 · 4 comments
Assignees
Labels
Milestone

Comments

@krzysztofmarzec3
Copy link

I have an object with operational attribute nsAccountLock that allow to lock account in LDAP.

@Entry
public class User {
   //other attributes definition
    @Attribute(name = "nsAccountLock")
    private boolean nsAccountLock;
...
}

In my business layer i have changed the attribute to different value. Then I call method update(Object entry) from LdapTemplate. Method throw org.springframework.ldap.AttributeInUseException: [LDAP: error code 20 - Attribute Or Value Exists];

From my perspective the problem is with method
_DirContextOperations context = lookupContext(id);_
because the return context don't have fetched operational attributes in originalAttr. Operational attributes will be returned from LDAP if you directly request for them.
This cause that modifyAttributes(context) will try to add once again "nsAccountLock" attribute but it is not possible beacuse such attribue exist and ldap throw exception.

In my opinion the code in update method should look like

DirContextAdapter context = lookup(id, entry.getClass());
context.setUpdateMode(true);
odm.mapToLdapDataEntry(entry, context);
modifyAttributes(context);

and the lookup method should look like:

    private DirContextAdapter lookup(final Name dn, final Class<?> clazz) {
        ObjectDirectoryMapper odm = getObjectDirectoryMapper();
        final String[] attributes = odm.manageClass(clazz);

        return executeReadOnly(new ContextExecutor<DirContextAdapter>() {
            public DirContextAdapter executeWithContext(DirContext ctx) throws NamingException {
                Attributes filteredAttributes = ctx.getAttributes(dn, attributes);
                DirContextAdapter contextAdapter = new DirContextAdapter(filteredAttributes, dn);
                return contextAdapter;
            }
        });
    }

to fetch all attributes mapped in ODM object.

Please fix this bug.

@sparse91
Copy link

sparse91 commented May 8, 2018

Hi. same here. any workarounds?

@floriancaillet
Copy link

Hi. same here too.
Lookup don't fetch all attributes mapped in ODM object

@mklopp
Copy link

mklopp commented Aug 8, 2023

I ran into the same issue.
Any news on this?

@jzheaux jzheaux self-assigned this Oct 2, 2024
@jzheaux jzheaux added this to the 3.2.x milestone Oct 2, 2024
@jzheaux jzheaux modified the milestones: 3.2.x, 3.2.7 Oct 9, 2024
@jzheaux
Copy link
Contributor

jzheaux commented Oct 9, 2024

@krzysztofmarzec3, thank you for the detailed report.

I agree that it makes sense to fetch all ODM attributes when retrieving an ODM-mapped entry.

I've scheduled this ticket for the next release.

@jzheaux jzheaux added type: bug A general bug in: core labels Oct 9, 2024
@jzheaux jzheaux changed the title When updating operational attribute in object via update(Object entry) method throw org.springframework.ldap.AttributeInUseException instead of update attribute Operational Attributes support should not require read-only attributes Oct 10, 2024
jzheaux added a commit that referenced this issue Oct 10, 2024
Added some test fixtures to reduce mocking that was dependent on
implementation details not under test.

With these in place, it is easier to construct test versions of
common javax.naming constructs while focusing on mocking
Spring LDAP behavior.

Issue gh-446
jzheaux added a commit that referenced this issue Oct 10, 2024
Made more robust by verifying fewer implementation details
and relying more on expected outcomes

Issue gh-446
jzheaux added a commit that referenced this issue Oct 10, 2024
Added some test fixtures to reduce mocking that was dependent on
implementation details not under test.

With these in place, it is easier to construct test versions of
common javax.naming constructs while focusing on mocking
Spring LDAP behavior.

Issue gh-446
jzheaux added a commit that referenced this issue Oct 10, 2024
Made more robust by verifying fewer implementation details
and relying more on expected outcomes

Issue gh-446
jzheaux added a commit that referenced this issue Oct 10, 2024
In this way, if an Entry has an operational attribute, it will
be present in both the updated and existing objects so that
DirContextAdapter does not compute it as a new attribute.

Closes gh-446
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Status: No status
Development

No branches or pull requests

5 participants