306654 - IO exception when decode vitual list control data section

Status: RESOLVED FIXED

(Directory :: LDAP Java SDK, defect)

Description

[Minghui Liu]

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; .NET CLR 1.1.4322)
Build Identifier: LDAP SDK/4.17

The problem:
I could not decode the sub filter sent by Outlook which is hidden in a 
virtuallistcontrol requrest’s data section, using the library, as it throws IO 
exception:

java.io.IOException

            at netscape.ldap.client.JDAPBERTagDecoder.getElement(Unknown Source)

            at netscape.ldap.ber.stream.BERTag.<init>(Unknown Source)

            at netscape.ldap.ber.stream.BERElement.getElement(Unknown Source)

            at netscape.ldap.ber.stream.BERConstruct.<init>(Unknown Source)

            at netscape.ldap.ber.stream.BERSequence.<init>(Unknown Source)

            at netscape.ldap.ber.stream.BERElement.getElement(Unknown Source)

            at com.intraspect.ldap.server.LDAPVirtualListRequest.parseResponse
(LDAPVirtualListRequest.java:109)

            at com.intraspect.ldap.server.LDAPVirtualListRequest.<init>
(LDAPVirtualListRequest.java:97)

            at com.intraspect.ldap.server.LDAPConnection.processSearchRequest
(LDAPConnection.java:379)

            at com.intraspect.ldap.server.LDAPConnection.processResponse
(LDAPConnection.java:156)

            at com.intraspect.ldap.server.LDAPConnection.run
(LDAPConnection.java:73)

            at com.intraspect.util.ThreadPoolThread.run
(ThreadPoolThread.java:73)

I fixed it in the following codes: (JDAPBERTagDecoder: getElement)

It is hard to say this is an Outlook bug or a library bug, as you can see the 
current comments in the library source: 

/* 16/02/97 MS specific */

…

            case 0x81:

                element = new BEROctetString(decoder, stream, 
bytes_read);       -> I added this part.

                implicit[0] = true;

            break;

            case 0x85:  /* Context Specific [5]:

                 * (a) Handle Microsoft v3 referral bugs! 
(Response)                   -> some existing codes

                 * (b) Handle Microsoft v3 supportedVersion in Bind

                 *     response            

                 */

                element = new BERInteger(stream, bytes_read);

                implicit[0] = true;

            break;

 

 …



Reproducible: Always

Steps to Reproduce:
Using outlook to send a search request with a virtuallist control and also the 
control has a subfilter in it.  
Actual Results:  
IO exception when I used the library.

Expected Results:  
The data should be decoded properly.

I provided the fix, could you confirm it is correct?

Comment 1

[Mark Banner (:standard8)]

*** Bug 306707 has been marked as a duplicate of this bug. ***

Comment 2

[Rich Megginson]

Upon further investigation, I'm not sure this is the right fix, or if this is
even a bug at all.  In the Fedora Directory Server, which does support VLV, the
tag value 0x81 is interpreted as LDAP_TAG_VLV_BY_VALUE, meaning the client is
addressing the list by a string or DN value rather than an integer range.  In
which case, OctetString is the correct data type.  However, the value 0x81 is
also used by the Sort control for the Boolean reverse flag (see BerElement.java
- SK_REVERSE = 0x01 is OR'd with CONTEXT = 0x80 to form the value 0x81).  I
think you should be using a context sensitive BERTagDecoder.  E.g.
public class VLVBERTagDecoder extends JDAPBERTagDecoder {
    /* no constructor? */
    public BERElement getElement(BERTagDecoder decoder, int tag,
        InputStream stream, int[] bytes_read, boolean[] implicit)
        throws IOException {
        BERElement element = null;
        if (tag == 0x81) {
            	element = new BEROctetString(decoder, stream, bytes_read);
            	implicit[0] = true;
        } else { /* let super class handle it */
                element = super.getElement(decoder, tag, stream, bytes_read,
implicit);
        }
        return element;
    }
}

Then pass a new VLVBerTagDecoder() to your BERElement.getElement() request. 

Comment 3

[Minghui Liu]

I agree that my fix is a little tricky. But I think that the LDK framework 
should handle this case without the need to subclassing.

Thank you very much for clarifying this for me.

Ming

Comment 4

[Rich Megginson]

How could the ldapjdk handle this without the need of subclassing?  That is, how
can JDAPBERTagDecoder.getElement know what context it's in?  If it is decoding a
sort control, and gets a tag 0x81, it needs to decode it as a boolean, but if it
is decoding a vlv control, it needs to use octetstring.  If there is a better
way to do it, please let me know.

Comment 5

[Minghui Liu]

If this is context sensitive, then this particular decoding method should be 
overriden in the context class e.g. the virtuallistcontrol class. I know at 
present, the inheritance heirarchy does not automatically allow this, that's 
why I wonder if there is a better archetecture so it could handle context 
sensitive decoding.   

Comment 6

[Rich Megginson]

You are correct - it should be overridden in the vlv control class.  However,
the ldapjdk was designed for and is primarily used for the client side of the
LDAP protocol.  So the original designers probably didn't give much thought to
decoding request controls, which seems to be one of the few times you need to do
context sensitive tag checking.  However, decode or parseRequest methods would
facilitate testing (e.g. JUnit).  See LDAPVirtualListResponse for examples of
how the LDAPVirtualListControl class could be modified to do parsing (e.g. pass
the BER encoded byte[] to the constructor).

BTW, did you know that there is an Apache Directory Server project, written in Java?

Comment 7

[Minghui Liu]

Yes, I guessed that the main reason is this is primarily designed for client 
implementation...
I will modify the LDAPVirtualListControl class to do the parsing as you 
suggested.

Yes, I know the Apache Directory Server project. I had a look at it sometimes 
ago. As we've been using your JDK since our first implementation, so I decided 
to continue to use it.
Thanks a lot,
Ming