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 17:44:05 GMT
well, we can change the server behavior, but it won't be that easy. I
tried to change during the past hour, but the pb is that we have many
different cases :
- if the user doesn't pass any attributes, it defaults to '*'
- if a use passes at least an attribute, then we should discard '1.1'
and '*' attributes (btw, it's a potential bug we may have : searching
for "cn *" or "cn 1.1" should be rejected)

Now, we have two more special cases :
- the user is passing a single and empty attribute (30 04 04 00) : it
should be considered as a '*'
- the user is passing some attributes plus an empty one : (30 06 04 02
sn 04 00) : this is what we (get here.

I currently have a fix for 1.5, but I'm not sure I will inject it in 1.0...

Why do we have to workaround all the damn wrongly pieces of software
all around us ???)

Integration tests running...


On 8/28/07, Stefan Zoerner <stefan@labeo.de> wrote:
> Emmanuel Lecharny wrote:
>
> > 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 '*').
>
> You definitely breathe the byte streams ;-)
>
> Nevertheless I would recommend to raise a JIRA, I'll assign it to me.
> Later on I'll check all relevant LDAP servers, and see how they
> interpret this. And I will check whether this is a general Java SDK
> problem. If so, it is relevant.
>
> I don't think that migrating to a newer version of the SDK would help
> our users. If this is a problem related to the SDK (and not the
> LDAPSearch client of the SDK) we should consider to change the behavior,
> at least if all other servers behave differently.
>
> We can still mark it as "invalid", but we have documented our decision
> and the behavior in case others face the same problem.
>
> What do you think?
>
>
>


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

Mime
View raw message