[Date Prev][Date Next] [Chronological] [Thread] [Top]

Patch for OpenLDAP to handle '*' properly in search attribute lists (ITS#236)



Full_Name: Kartik Subbarao
Version: 1.2.4
OS: HP-UX 11.00
URL: ftp://ftp.openldap.org/incoming/Kartik-Subbarao-990724.patch
Submission from: (NULL) (208.0.42.34)


This patch makes OpenLDAP interpret '*' in a search attribute
list correctly, as specified by RFC 2251. (This was the final 
hurdle to overcome to get Netscape Communicator's Roaming 
access to work!).

This command demonstrates the problem:

ldapsearch -b o=suffix objectclass='*' '*' modifyTimestamp

OpenLDAP only returns the modifyTimestamp attributes of the
entries, when it should also be returning all of the user
attributes, as well as modifyTimestamp (an operational attribute):

Here is the relevant portion of RFC 2251, section 4.5.1:

=====
 - attributes: A list of the attributes to be returned from
each entry which matches the search filter. There are two
special values which may be used: an empty list with no
attributes, and the attribute description string "*".  Both of
these signify that all user attributes are to be returned.
(The "*" allows the client to request all user attributes in
addition to specific operational attributes).
=====

[An additional note: OpenLDAP doesn't seem to draw a
distinction between user attributes and operational attributes
(like modifyTimestamp). It will return them even without them
being explicitly queried for. I'm not sure if that's incorrect
behavior, or if it's in the realm of undefined behavior. It
doesn't seem to break anything, but based on my reading of
RFCs 2251 and 2252, I think it'd be better if OpenLDAP didn't
automatically return operational attributes.]

I kept the patch as simple as possible. I hope it fits in well
enough with your coding standards to be useful. I figure even
in the worst case, if you need to re-implement it some other
way, at least the basic change is simple to understand.

Regards,

	-Kartik

--
Email: subbarao@computer.org
WWW:   http://www.geocities.com/SiliconValley/Way/1234/