Issue 459 - Filter Issues
Summary: Filter Issues
Status: VERIFIED FIXED
Alias: None
Product: OpenLDAP
Classification: Unclassified
Component: slapd (show other issues)
Version: unspecified
Hardware: All All
: --- normal
Target Milestone: ---
Assignee: OpenLDAP project
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2000-02-21 16:44 UTC by jdmsys@rit.edu
Modified: 2014-08-01 21:06 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description Kurt Zeilenga 2000-02-21 12:33:56 UTC
changed notes
changed state Open to Test
Comment 1 Kurt Zeilenga 2000-02-21 12:34:04 UTC
moved from Incoming to Software Bugs
Comment 2 jdmsys@rit.edu 2000-02-21 16:44:47 UTC
Full_Name: Jeffrey Mahoney
Version: 1.2.9
OS: Digital UNIX 4.0Fpl1
URL: 
Submission from: (NULL) (129.21.253.31)


        I've recently upgraded from Umich 3.3 to OpenLDAP 1.2.9 (plus some
local authentication changes to support DCE).

        Unfortunately, some filters don't seem to work. Most painfully, is the
one that our CS&T (Corporate Time) Calendar Server uses.

        There seems to be a problem in the search filter code, I think.

        Example:

        ldapsearch -b "O=ROCHESTER INSTITUTE OF TECHNOLOGY,ST=NEW YORK,C=US" -h
ldap
"(&(ctcalxitemid=*)(&(&(sn=MAHONEY*)(givenname=JEFFREY*)(!(|(!(ctcalxitemid=00010:*))(objectclass=CTCALRESOURCE)(objectclass=CTCALADMIN))))(ctcalxitemid=00010:*)))"
dn

        ... returns 0 results; and ...

        ldapsearch -b "O=ROCHESTER INSTITUTE OF TECHNOLOGY,ST=NEW YORK,C=US" -h
ldap "(&(ctcalxitemid=*)(&(&(sn=MAHONEY*)(givenname=JEFFREY*)(!(
|(!(ctcalxitemid=00010:*))(objectclass=CTCALRESOURCE)(objectclass=CTCALADMIN))))(ctcalxitemid=00010:*)))"
dn

        ... returns 1 result (as expected.)

        The only difference between the two is the space preceding the |
character in the middle. Has anyone experienced similar problems? This
filter has worked perfectly for several months on our UMich 3.3 server.

        -Jeff
Comment 3 Kurt Zeilenga 2000-02-21 20:11:53 UTC
At 04:44 PM 2/21/00 GMT, jdmsys@rit.edu wrote:
>        The only difference between the two is the space preceding the |
>character in the middle. Has anyone experienced similar problems? 

The second filter is invalid and, as such, the behavior is undefined.

I've patched libldap/search.c to ignore erroneous spaces after a '(',
which should make your second filter behave like your first filter.

http://www.openldap.org/devel/cvsweb.cgi/libraries/libldap/search.c.diff?r1=1.4.2.3.2.2&r2=1.4.2.3.2.3

>This filter has worked perfectly for several months on our UMich 3.3 server.

How did U-Mich 3.3 react with the first filter?

	Kurt

Comment 4 jdmsys@rit.edu 2000-02-21 21:15:39 UTC
"Kurt D. Zeilenga" wrote:
> 
> At 04:44 PM 2/21/00 GMT, jdmsys@rit.edu wrote:
> >        The only difference between the two is the space preceding the |
> >character in the middle. Has anyone experienced similar problems?
> 
> The second filter is invalid and, as such, the behavior is undefined.
> 
> I've patched libldap/search.c to ignore erroneous spaces after a '(',
> which should make your second filter behave like your first filter.

	Unfortunately, this didn't seem to fix the problem. Now, it fails on
both variants.

> How did U-Mich 3.3 react with the first filter?

	UMich 3.3 responds with the correct matches for both.

	Thanks.

	-Jeff

--
Jeffrey Mahoney
Systems Programmer
Technical Support Group
Information Technology Services
Rochester Institute of Technology
Rochester, NY
Ph: 716-475-2258
Comment 5 Kurt Zeilenga 2000-02-21 21:56:43 UTC
At 09:15 PM 2/21/00 GMT, jdmsys@rit.edu wrote:
>Now, it fails on both variants.

As expected.

>Unfortunately, this didn't seem to fix the problem.

Does slapd indicate any candidates where found?
Does the list of candidates include the entry?
What does the entry look like?
Comment 6 Kurt Zeilenga 2000-03-10 15:37:22 UTC
changed state Test to Release
Comment 7 Kurt Zeilenga 2000-05-04 03:57:01 UTC
changed state Release to Closed
Comment 8 OpenLDAP project 2014-08-01 21:06:54 UTC
Fixed filter bug indicated by submission.