Directory ApacheDS
  1. Directory ApacheDS
  2. DIRSERVER-1701

ApacheDS doesn't return all the attributes when invoking DirContext.getAttributes(Name, null)

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Invalid
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None
    • Environment:

      Description

      ApacheDS doesn't return all the attributes when invoking javax.naming.directory.DirContext.getAttributes(Name, null)

      Running some unit tests as described here: http://directory.apache.org/apacheds/1.5/42-using-apacheds-for-unit-tests.html
      Using a ldif file.

      When the following code is esecuted:
      ...
      env.put("java.naming.ldap.attributes.binary",
      ATTR_OBJECTSID ' ' ATTR_OBJECTGUID+ ' '+"entryUUID");
      ctx = javax.naming.ldap.InitialLdapContext(env,null);
      .....
      attrIds = null;
      attrs = ctx.getAttributes(distinguishedName, attrIds);

      attrs doesn't contain ALL the attributes as specified by the JavaDoc
      attrIds - the identifiers of the attributes to retrieve. null indicates that all attributes should be retrieved;
      http://docs.oracle.com/javase/6/docs/api/javax/naming/directory/DirContext.html#getAttributes(javax.naming.Name, java.lang.String[])

      Using the same code against other directory servers returns all the attributes.

      -----------
      Returned:
      dn: ou=3809,ou=system
      objectclass: organizationalUnit
      objectclass: top
      ou: 3809
      description: Description goes here
      l: testgroup@test.com
      postalcode: Group Name

      Expected:
      dn: ou=3809,ou=system
      objectclass: organizationalUnit
      objectclass: top
      ou: 3809
      description: Description goes here
      l: testgroup@test.com
      postalcode: Group Name
      createTimestamp: 20120316074659Z
      creatorsName: 0.9.2342.19200300.100.1.1=admin,2.5.4.11=system
      entryCSN: 20120316074659.800000Z#000000#000#000000
      entryParentId: 1
      entryUUID:: ZjBkNDQ5NjUtMDMxMy00YWI2LTg5YzMtYzY0NDQ5N2YwOWVh
      -------
      Log:

      6:49:38 [DEBUG] registries.DefaultSchemaObjectRegistry - Found ATTRIBUTE_TYPE ( 2.16.840.1.113730.3.1.34
      NAME 'ref'
      DESC namedref: subordinate referral URL
      EQUALITY caseExactMatch
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
      USAGE distributedOperation
      )
      with oid: ref (DefaultSchemaObjectRegistry.java:181)
      16:49:38 [DEBUG] handlers.SearchHandler - Sending ou=3809,ou=system (SearchHandler.java:401)
      16:49:38 [DEBUG] filterchain.IoFilterEvent - Event MESSAGE_RECEIVED has been fired for session 3 (IoFilterEvent.java:118)

        Activity

        Hide
        Javier Alcázar added a comment -

        Thanks!

        ApacheDS great product, great support

        Show
        Javier Alcázar added a comment - Thanks! ApacheDS great product, great support
        Hide
        Pierre-Arnaud Marcelot added a comment -

        Exactly, that's what I explained above.

        Show
        Pierre-Arnaud Marcelot added a comment - Exactly, that's what I explained above.
        Hide
        Javier Alcázar added a comment -

        Thanks Emmanuel,

        One more question:

        When using attrIds=new String[]

        {"*","+"}


        Am I listing all operational attributes by using"*","+"?
        If so, "+" used in conjunction with "*" does mean all user and operational attributes?

        Show
        Javier Alcázar added a comment - Thanks Emmanuel, One more question: When using attrIds=new String[] {"*","+"} Am I listing all operational attributes by using"*","+"? If so, "+" used in conjunction with "*" does mean all user and operational attributes?
        Hide
        Javier Alcázar added a comment -

        I see, thanks again.

        Show
        Javier Alcázar added a comment - I see, thanks again.
        Hide
        Emmanuel Lecharny added a comment -

        Still invalid...

        Show
        Emmanuel Lecharny added a comment - Still invalid...
        Hide
        Emmanuel Lecharny added a comment -

        You misinterpreted the 4.5.1.8 section :

        "2. A list containing "*" (with zero or more attribute
        descriptions) requests the return of all user attribute"

        (so far, so good, we are compliant)

        "in addition to other listed (operational) attributes. "

        Here, "listed" means the opAttr you have added in your request. If you don't add any, you will not get any.

        Well, we are definitively compliant

        Show
        Emmanuel Lecharny added a comment - You misinterpreted the 4.5.1.8 section : "2. A list containing "*" (with zero or more attribute descriptions) requests the return of all user attribute" (so far, so good, we are compliant) "in addition to other listed (operational) attributes. " Here, "listed" means the opAttr you have added in your request. If you don't add any, you will not get any. Well, we are definitively compliant
        Hide
        Javier Alcázar added a comment -

        Thanks for the quick response!
        And thanks for enlightening me.
        =)

        I haven't read "The attributes returned do not include operational attributes" under the section
        "Operational Attributes" in http://docs.oracle.com/javase/6/docs/api/javax/naming/directory/DirContext.html
        My mistake.

        However ApacheDS 2.0.0-M3 migth not be behaving as it should.

        Section "4.5.1.8. SearchRequest.attributes" of "Lightweight Directory Access Protocol (LDAP): The Protocol" in http://www.ietf.org/rfc/rfc4511.txt states:
        .....
        2. A list containing "*" (with zero or more attribute
        descriptions) requests the return of all user attributes in
        addition to other listed (operational) attributes.

        So, if my understanding is correct, specifying "*" should return operational attributes too, but
        ApacheDS 2.0.0-M3 only returns user attributes.
        Is this correct?

        ctx.getAttributes(distinguishedName, attrIds)

        attrIds=new String[]

        {"*"} {postalcode=postalCode: Group Name, l=l: testgroup@test.com, ou=ou: 3809, description=description: Description goes here, objectclass=objectClass: organizationalUnit, top}

        attrIds=new String[]

        {"*","+"} {ou=ou: 3809, l=l: testgroup@test.com, entryuuid=entryUUID: [B@933bcb, entrycsn=entryCSN: 20120315164829.327000Z#000000#000#000000, objectclass=objectClass: organizationalUnit, top, modifytimestamp=modifyTimestamp: 20120315104630Z, modifiersname=modifiersName: 0.9.2342.19200300.100.1.1=admin,2.5.4.11=system, postalcode=postalCode: Group Name, createtimestamp=createTimestamp: 20120315074829Z, creatorsname=creatorsName: 0.9.2342.19200300.100.1.1=admin,2.5.4.11=system, description=description: Description goes here}
        Show
        Javier Alcázar added a comment - Thanks for the quick response! And thanks for enlightening me. =) I haven't read "The attributes returned do not include operational attributes" under the section "Operational Attributes" in http://docs.oracle.com/javase/6/docs/api/javax/naming/directory/DirContext.html My mistake. However ApacheDS 2.0.0-M3 migth not be behaving as it should. Section "4.5.1.8. SearchRequest.attributes" of "Lightweight Directory Access Protocol (LDAP): The Protocol" in http://www.ietf.org/rfc/rfc4511.txt states: ..... 2. A list containing "*" (with zero or more attribute descriptions) requests the return of all user attributes in addition to other listed (operational) attributes. So, if my understanding is correct, specifying "*" should return operational attributes too, but ApacheDS 2.0.0-M3 only returns user attributes. Is this correct? ctx.getAttributes(distinguishedName, attrIds) attrIds=new String[] {"*"} {postalcode=postalCode: Group Name, l=l: testgroup@test.com, ou=ou: 3809, description=description: Description goes here, objectclass=objectClass: organizationalUnit, top} attrIds=new String[] {"*","+"} {ou=ou: 3809, l=l: testgroup@test.com, entryuuid=entryUUID: [B@933bcb, entrycsn=entryCSN: 20120315164829.327000Z#000000#000#000000, objectclass=objectClass: organizationalUnit, top, modifytimestamp=modifyTimestamp: 20120315104630Z, modifiersname=modifiersName: 0.9.2342.19200300.100.1.1=admin,2.5.4.11=system, postalcode=postalCode: Group Name, createtimestamp=createTimestamp: 20120315074829Z, creatorsname=creatorsName: 0.9.2342.19200300.100.1.1=admin,2.5.4.11=system, description=description: Description goes here}
        Hide
        Pierre-Arnaud Marcelot added a comment -

        RFC 4511 "Lightweight Directory Access Protocol (LDAP): The Protocol" [1] indicates this:
        1. An empty list with no attributes requests the return of all user attributes.

        So, ApacheDS handles this correctly. Other directory servers don't.

        [1] - http://www.ietf.org/rfc/rfc4511.txt

        Show
        Pierre-Arnaud Marcelot added a comment - RFC 4511 "Lightweight Directory Access Protocol (LDAP): The Protocol" [1] indicates this: 1. An empty list with no attributes requests the return of all user attributes. So, ApacheDS handles this correctly. Other directory servers don't. [1] - http://www.ietf.org/rfc/rfc4511.txt
        Hide
        Emmanuel Lecharny added a comment -

        Pretty normal behavior : if neither '+' nor the expected operational attributes are provided in the request, only the user Attributes will be returned. This is plain compliant with the LDAP RFC.

        Show
        Emmanuel Lecharny added a comment - Pretty normal behavior : if neither '+' nor the expected operational attributes are provided in the request, only the user Attributes will be returned. This is plain compliant with the LDAP RFC.
        Hide
        Pierre-Arnaud Marcelot added a comment -

        My mistake, actually, we return all "user" attributes but "operational" attributes are omitted.

        I tracked the request in the server and we receive a request with no attributes (as one can expect).
        I'm not sure what the LDAP spec says about that.

        In any case, you'd better use and specify these two options as your attributes:

        • '*' which asks for all user attributes
        • '+' which asks for all operational attributes
        Show
        Pierre-Arnaud Marcelot added a comment - My mistake, actually, we return all "user" attributes but "operational" attributes are omitted. I tracked the request in the server and we receive a request with no attributes (as one can expect). I'm not sure what the LDAP spec says about that. In any case, you'd better use and specify these two options as your attributes: '*' which asks for all user attributes '+' which asks for all operational attributes
        Hide
        Pierre-Arnaud Marcelot added a comment -

        What version of ApacheDS are you using?

        I tested over the latest trunk and it works as expected.

        Show
        Pierre-Arnaud Marcelot added a comment - What version of ApacheDS are you using? I tested over the latest trunk and it works as expected.

          People

          • Assignee:
            Unassigned
            Reporter:
            Javier Alcázar
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development