directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ralf Hauser (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DIRSERVER-651) query incorrectly parsed if first part contains wild-cards (asterisk) - most prominently for gpg/gnupg
Date Sun, 09 Jul 2006 09:49:30 GMT
    [ http://issues.apache.org/jira/browse/DIRSERVER-651?page=comments#action_12419897 ] 

Ralf Hauser commented on DIRSERVER-651:
---------------------------------------

Interestingly, already very early when doing the request with ldapsearch, the server only
sees the "disabled=0" part:
Thread [IoThreadPool-1] (Suspended (breakpoint at line 148 in org.apache.directory.shared.ldap.message.MessageDecoder$1))
	org.apache.directory.shared.ldap.message.MessageDecoder$1.decodeOccurred(org.apache.directory.shared.asn1.codec.stateful.StatefulDecoder,
java.lang.Object) line: 148
	org.apache.directory.shared.ldap.codec.TwixDecoder.decode(java.lang.Object) line: 114
	org.apache.directory.shared.ldap.message.MessageDecoder.decode(java.lang.Object) line: 206
	org.apache.mina.filter.codec.asn1.Asn1CodecDecoder.decode(org.apache.mina.common.IoSession,
org.apache.mina.common.ByteBuffer, org.apache.mina.filter.codec.ProtocolDecoderOutput) line:
37
	org.apache.mina.filter.codec.ProtocolCodecFilter.messageReceived(org.apache.mina.common.IoFilter$NextFilter,
org.apache.mina.common.IoSession, java.lang.Object) line: 56
	org.apache.mina.transport.socket.nio.support.SocketFilterChain(org.apache.mina.common.support.AbstractIoFilterChain).callNextMessageReceived(org.apache.mina.common.IoFilterChain$Entry,
org.apache.mina.common.IoSession, java.lang.Object) line: 494
	org.apache.mina.common.support.AbstractIoFilterChain.access$1000(org.apache.mina.common.support.AbstractIoFilterChain,
org.apache.mina.common.IoFilterChain$Entry, org.apache.mina.common.IoSession, java.lang.Object)
line: 52
	org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.messageReceived(org.apache.mina.common.IoSession,
java.lang.Object) line: 761
	org.apache.mina.filter.ThreadPoolFilter.processEvent(org.apache.mina.common.IoFilter$NextFilter,
org.apache.mina.common.IoSession, org.apache.mina.filter.ThreadPoolFilter$EventType, java.lang.Object)
line: 665
	org.apache.mina.filter.ThreadPoolFilter$Worker.processEvents(org.apache.mina.filter.ThreadPoolFilter$SessionBuffer)
line: 421
	org.apache.mina.filter.ThreadPoolFilter$Worker.run() line: 376

LdapMessage
    message Id : 2
    Search Request
        Base Object : 'dc=pgpkeys'
        Scope : whole subtree
        Deref Aliases : never Deref Aliases
        Size Limit : no limit
        Time Limit : no limit
        Types Only : false
        Filter : '(pgpdisabled=0)'

and then, in ExprNode org.apache.directory.shared.ldap.codec.TwixTransformer.transformFilter(Filter
twixFilter), only an Filter twixFilter= AttributeValueAssertionFilter  (id=3647) is seen.

When doing the same without the asterisk in the query, already in decodeOccurred(), the LdapMessage
contains both parts of the query
LdapMessage
    message Id : 2
    Search Request
        Base Object : 'dc=pgpkeys'
        Scope : whole subtree
        Deref Aliases : never Deref Aliases
        Size Limit : no limit
        Time Limit : no limit
        Types Only : false
        Filter : '(&(pgpuserid=vgjokjev@netcetera.com.mk)(pgpdisabled=0))'

So either already the org.apache.directory.shared.ldap.message.MessageDecoder doesn't decode
the queries with asterisks correctly or it is the clients that do not send the combined query
as soon as there is the asterisk.

I'll attach two ldapsearch logs with debug output.
My intuition tells me that since gpg and ldapsearch behave the same way, that this isn't a
client issue (and seeing what the client sends by changing "-d5" to "-d999" hints at that
too), but this cold be easily verifed with an etheral sniffing session.


> 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
>  Attachments: ldapAsterisk.txt, ldapNoAsterisk.txt
>
> As reported by Valdimir (http://mail-archives.apache.org/mod_mbox/directory-dev/200606.mbox/ajax/%3c4492B645.9020205@netcetera.com.mk%3e)
 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=pgpkeys"
"(&(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.FilterParserImpl,
it appears that when doing my tests, the parse() is never called??

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


Mime
View raw message