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

LDAP-96: The order of a multi-valued attribute is not preserved by modifyAttributes(DirContextOperations) #136

Closed
spring-issuemaster opened this issue Jan 4, 2008 · 4 comments
Labels
Milestone

Comments

@spring-issuemaster
Copy link

@spring-issuemaster spring-issuemaster commented Jan 4, 2008

Jürgen Failenschmid(Migrated from LDAP-96) said:

As an example, consider two values of attribute “title”: [“Juergen”, “George”].

In my mapToContext method I do something like:

context.setAttributeValues(“title”, values, true), // order matters

where values now contains [“George”, “Juergen”], i.e., the values have been permuted.
Then the DAO update method does something like this:

```
final DistinguishedName dn = buildDn(principal.getUserId());
DirContextOperations context = getLdapOperations().lookupContext(
dn.encode());
mapToContext(context, principal, password);
getLdapOperations().modifyAttributes(context);
```

After the update, fetching the new values using adapter.getStringAttributes() shows that the values are in the wrong, original order.
Stepping through modifyAttributes(), it appears that DirContextAdapter.collectModifications(Attribute, Attribute, List)
does not implement anything special to consider preserving the order of values of a multi-valued attribute.

@spring-issuemaster

This comment has been minimized.

Copy link
Author

@spring-issuemaster spring-issuemaster commented Mar 27, 2008

Mattias Hellborg Arthursson said:

Estimate may be too high. Quite possible this is easier to fix than that.

@spring-issuemaster

This comment has been minimized.

Copy link
Author

@spring-issuemaster spring-issuemaster commented Jun 18, 2008

Mattias Hellborg Arthursson said:

Quite right, ordering was not taken into consideration when calculating the @ModificationItem@s. Added this as a special case in DirContextAdapter#collectModifications(Attribute changedAttr, List modificationList); changed multivalue attributes that are ordered will be replaced in their entirety.

@spring-issuemaster

This comment has been minimized.

Copy link
Author

@spring-issuemaster spring-issuemaster commented Oct 16, 2008

Brian Relph said:

Unfortunately, I don’t think that LDAP can be used to store ordered attributes, if I understand the specification [ http://www.ietf.org/rfc/rfc2251.txt ] correctly:

4.1.8. Attribute

Each attribute value is distinct in the set (no duplicates). The order of attribute values within the vals set is undefined and implementation-dependent, and MUST NOT be relied upon.

@spring-issuemaster

This comment has been minimized.

Copy link
Author

@spring-issuemaster spring-issuemaster commented Oct 16, 2008

Jürgen Failenschmid said:

Other functions of Spring LDAP rely on ordering of attributes, otherwise the order-related features wouldn’t be there at all.

The blurb of RFC2251 about “must not rely” upon the ordering of attribute values needs to be read in the context of “is undefined and implementation-dependent”. The RFC does not mean that an LDAP implementation could not provide deterministic ordering of attributes.
Relying on ordering could be problematic if the underlying LDAP implementation is changed – which is done infrequently, and problematic for other reasons anyway (e.g. extended operations, controls)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
1 participant
You can’t perform that action at this time.