directory-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Emmanuel Lecharny" <elecha...@gmail.com>
Subject Re: Unrequested attributes returned on ldap search
Date Tue, 28 Aug 2007 16:34:53 GMT
Thanks Stefan.

This is a clear client bug. The client just add an empty attribute at
the end of the attributes list :
...
    30 06   // Attributes list
      04 02 // 2 chars length attribute
        sn   // sn is requested
      04 00 // 0 length attribute.

In this very case, we are 'interpreting the spec by considering that
asking for an empty attribute means we want all the attributes ("*")
(nothing in the RFC states that if we have an empty attribute we
should discard it, but if the list is itself empty, then it should be
considered as '*'. I added a special case : if one attribute is empty,
then it is considered as if the user injected a '*').

In my mind, there is a simple solution : update to a newer version of
LdapSearch, or report a bug to Mozilla.org...

On 8/28/07, Stefan Zoerner <stefan@labeo.de> wrote:
> Emmanuel Lecharny wrote:
> > I think it's definitively a bug in the LdapSearch client : the
> > twixDecoder logs show that the incoming request contains a star.
> >
> > I would like to get the bytes sent by the client. You have a way to
> > get a byte dump of the request somwhere in the logs you generated. Can
> > you copy/past them ?
> >
> > Thanks !
>
> I perform a search with the problematic tool (-v is verbose and shows
> the options) ...
>
> C:\java\Sun ONE Directory SDK for Java 4.1\tools>java -cp
> ../packages/ldapjdk.jar LDAPSearch -h degas -p 389 -b
> "DC=TIVOLIDS,DC=DEGAS" -v "(cn=Tori*)" sn
>
> filter pattern: (cn=Tori*)
> returning: sn
> filter is: ((cn=Tori*))
>
> dn: cn=Tori Amos,DC=TIVOLIDS,DC=DEGAS
> sn: Amos
>
> ---
>
> This is what I get from Wireshark for the packet wich contains the
> search request:
>
> 0000  08 00 20 86 dd a6 00 13  a9 29 8a 28 08 00 45 00   .. ..... .).(..E.
> 0010  00 6a f1 b6 40 00 80 06  75 5a c0 a8 09 26 c0 a8   .j..@... uZ...&..
> 0020  09 06 12 78 01 85 97 20  d7 66 0f 82 d8 ec 50 18   ...x...  .f....P.
> 0030  ff e9 93 d9 00 00 30 40  02 01 02 63 3b 04 14 44   ......0@ ...c;..D
> 0040  43 3d 54 49 56 4f 4c 49  44 53 2c 44 43 3d 44 45   C=TIVOLI DS,DC=DE
> 0050  47 41 53 0a 01 02 0a 01  00 02 01 00 02 01 00 01   GAS..... ........
> 0060  01 00 a4 0c 04 02 63 6e  30 06 80 04 54 6f 72 69   ......cn 0...Tori
> 0070  30 06 04 02 73 6e 04 00                            0...sn..
>
> Please note that I had to communicate with a TivoliDS, because ApacheDS
> is currently not installed on a server I can grab with Wireshark. If
> this is a problem, I can change this.
>
> The interesting thing is the attributes part, which seems to contain 2
> items (this is what Wireshark states in the pretty print)
>
> attributes: 2 items
>      Item: sn
>      Item:
>
> With the native tool (which works with ApacheDS), the same request goes
> this:
>
> 0000   08 00 20 86 dd a6 00 13 a9 29 8a 28 08 00 45 00  .. ......).(..E.
> 0010   00 68 f3 33 40 00 80 06 73 df c0 a8 09 26 c0 a8  .h.3@...s....&..
> 0020   09 06 12 7c 01 85 9e b5 40 53 16 f4 07 c3 50 18  ...|....@S....P.
> 0030   ff ff 93 d7 00 00 30 3e 02 01 01 63 39 04 14 64  ......0>...c9..d
> 0040   63 3d 54 69 76 6f 6c 69 44 53 2c 64 63 3d 64 65  c=TivoliDS,dc=de
> 0050   67 61 73 0a 01 02 0a 01 00 02 01 00 02 01 00 01  gas.............
> 0060   01 00 a4 0c 04 02 63 6e 30 06 80 04 54 6f 72 69  ......cn0...Tori
> 0070   30 04 04 02 73 6e                                0...sn
>
> Note the attributes at the end. Wireshark says:
>
> attributes: 1 item
>      Item: sn
>
> This might be the problem. Note that TivoliDS returns the correct result
> in both cases, so we should perhaps fix it, even if the client acts strange.
>
> Greetings,
>      Stefan
>
>
>
>
>


-- 
Regards,
Cordialement,
Emmanuel L├ęcharny
www.iktek.com

Mime
View raw message