query incorrectly parsed if first part contains wild-cards (asterisk) - most
 prominently for gpg/gnupg
----------------------------------------------------------------------------
--------------------------

Key: DIRSERVER-651
URL: http://issues.apache.org/jira/browse/DIRSERVER-651
Project: Directory ApacheDS
Type: Bug

Environment: all
Reporter: Ralf Hauser


As reported by Valdimir ([url]http://mail-archives.apache.org/mod_mbox/directory-dev/20
0606.mbox/ajax/%3c4492B645.9020205-vkGj3nKBv858Tp6GviizRw@public.gmane.org%3e[/url
])  this query is not handled correctly.

In short:
ldapsearch -x -H ldap://localhost:11500 -D "dn=bugs" -w bunny -b "dc=pgpkeys
" "(&(pgpuserid=test*)(pgpdisabled=0))"
only brings up a SimpleNode instead of a BranchNode.

Some further insights:
-----------------
1) a unit test on the query with the parser in shared-ldap-0.9.5.jar appears
 to work:
FilterParserImpl parser = new FilterParserImpl();
ExprNode node = parser
.parse("(&(pgpuserid=*@test*)(pgpdisabled=0))");
==> a BranchNode is returned here, but not when using apacheDS
2) when switching the order of the sub-queries, I do see the BranchNode even
 when using apacheDS with both parts:
ldapsearch -x -H ldap://localhost:2389 -d5 -D "dn=bugs" -w bunny -b "dc=pgpk
eys" "(&(pgpdisabled=0)(pgpuserid=@test*))"
3) increasing the debug level to "ldapsearch -d10" hints that the full query
 is sent to apacheDS and not only the "pgpdisabled=0" part
4) when setting a break-point in org.apache.directory.shared.ldap.filter.Fil
terParserImpl, it appears that when doing my tests, the parse() is never cal
led??


--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secur...nistrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira

[ Post a follow-up to this message ]