You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by "Stefan Zoerner (JIRA)" <ji...@apache.org> on 2006/06/08 17:30:29 UTC
[jira] Created: (DIRSERVER-638) Searches with escaped characters in
the base DN fail.
Searches with escaped characters in the base DN fail.
-----------------------------------------------------
Key: DIRSERVER-638
URL: http://issues.apache.org/jira/browse/DIRSERVER-638
Project: Directory ApacheDS
Type: Bug
Versions: 1.0-RC3
Environment: ApacheDS 1.0 RC 3
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_04-b05)
Microsoft Windows XP version 5.1 Service Pack 1
Reporter: Stefan Zoerner
Searches with escaped characters in the base DN fail. I have created a test entry like this:
dn: sn=Ferry,dc=example,dc=com
objectclass: top
objectclass: person
sn: Ferry
cn: Bryan Ferry
and perform searches with the following parameters
1)
BASE DN: sn=\46\65\72\72\79,dc=example,dc=com
Filter: (cn=Bryan Ferry)
Scope: BASE
2)
BASE DN: sn=#4665727279,dc=example,dc=com
Filter: (cn=Bryan Ferry)
Scope: BASE
In both cases the entry is not found, although it should (see examples in Chapter 5 of RFC 2253). In example 1 the search base is the DN of the example with "Ferry" escaped with backslashes. The second example is the same search base, but with the value BER encoded (octet String).
An attached JUnit test creates the entry and performs both search ops. It passes with Sun Java System Directory Server 5.2 but fails with ApacheDS.
--
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
[jira] Commented: (DIRSERVER-638) Searches with escaped characters
in the base DN fail.
Posted by "Emmanuel Lecharny (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DIRSERVER-638?page=comments#action_12426456 ]
Emmanuel Lecharny commented on DIRSERVER-638:
---------------------------------------------
np at all, A.
It's just that I wasn't very pleased with the way I wrote this part when I browsed the source before leaving, and in the train, I found that it need some rewrite. I thrown some comment in Confluence in, order to keep it available for when I will be back.
Your fix was perfect. What you did ws what I had in mind : doing it in Normalizer.
We will be able to discuss those points forward when I will be back, for 2.0 version.
Thanks for the fix, btw :)
E., having fun.
> Searches with escaped characters in the base DN fail.
> -----------------------------------------------------
>
> Key: DIRSERVER-638
> URL: http://issues.apache.org/jira/browse/DIRSERVER-638
> Project: Directory ApacheDS
> Issue Type: Bug
> Affects Versions: 1.0-RC3
> Environment: ApacheDS 1.0 RC 3
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_04-b05)
> Microsoft Windows XP version 5.1 Service Pack 1
> Reporter: Stefan Zoerner
> Assigned To: Alex Karasulu
> Fix For: 1.1.0, 1.0-RC4
>
> Attachments: SearchWithEscapedCharacters.java
>
>
> Searches with escaped characters in the base DN fail. I have created a test entry like this:
> dn: sn=Ferry,dc=example,dc=com
> objectclass: top
> objectclass: person
> sn: Ferry
> cn: Bryan Ferry
> and perform searches with the following parameters
> 1)
> BASE DN: sn=\46\65\72\72\79,dc=example,dc=com
> Filter: (cn=Bryan Ferry)
> Scope: BASE
> 2)
> BASE DN: sn=#4665727279,dc=example,dc=com
> Filter: (cn=Bryan Ferry)
> Scope: BASE
> In both cases the entry is not found, although it should (see examples in Chapter 5 of RFC 2253). In example 1 the search base is the DN of the example with "Ferry" escaped with backslashes. The second example is the same search base, but with the value BER encoded (octet String).
> An attached JUnit test creates the entry and performs both search ops. It passes with Sun Java System Directory Server 5.2 but fails with ApacheDS.
--
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
[jira] Commented: (DIRSERVER-638) Searches with escaped characters
in the base DN fail.
Posted by "Emmanuel Lecharny (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DIRSERVER-638?page=comments#action_12426029 ]
Emmanuel Lecharny commented on DIRSERVER-638:
---------------------------------------------
Yes, I think I introduced a regression in the current parser. Octothrops Strings and PairChar or escaped characters are currently parsed, but not transformed to their counterparts.
However, this is a complicated one (with DIRSERVER-631) in that the current LdapDN structure will not be able to store those values correctly - except for escaped chars- AFAIR.
We have three cases :
- <oid>=#<hexPairs>* : the value is binary and should be stored in a byte[]
- <attrType> = <String with escaped chars like \+ : those escaped chars should be transformed to their real values in the attributeValue
- <attrType> = <String with PairChars like \4A> : the problem here is that this is supposed to be a String, so those HexPair are supposed to represent valid UTF-8 sequences, which could perfectly be wrong. The parser then have to check that those values are correct, and transform them to their chars counterpart. Remember that DN are transfered as bytes representingan UTF-8 encoded value.
Alex, if it can wait, I can handle this JIRA and DIRSERVER-631 when I'll be back. Not that I don't think that you won't be able to fix the code, or that I don't want you to touch *my* code (you know, the *it's my code* syndrom), but much more because it's because the regression is my fault. This piece of code is a little bloated, because I'm working with the initial UP String, and a Position Objet, and many methods in StringTools return a number of bytes read instead of the resultant char (was thinking of isHexPair), so you may need to re-read and parse those hexPair a second time to store the result. The result is generally a subString of the original DN, because I don't create a subString to store the attributeValue.
Also keep in mind that we have no clue during the parsing phase about the attribute type : is it binary or not? This is a not resolved question : binary are allowed as a part of a DN, but should they be coded in the first form (oid=#<hex>*) or may they be encoded this way : <attr>=<escaped hexPairs>*. May be the best place to do the ransformation is in the Normalization service, thus the AttributeValue should be kept as byte[] until then.
I have started to think about DN parsing on confluence : http://docs.safehaus.org/display/APACHEDS/DN+Parsing
with a better structure to hold all the needed information (it will be very helpfull for ModifyRDN operation)
Let's start a little discussion about those ponts before coding, it can save us some time.
> Searches with escaped characters in the base DN fail.
> -----------------------------------------------------
>
> Key: DIRSERVER-638
> URL: http://issues.apache.org/jira/browse/DIRSERVER-638
> Project: Directory ApacheDS
> Issue Type: Bug
> Affects Versions: 1.0-RC3
> Environment: ApacheDS 1.0 RC 3
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_04-b05)
> Microsoft Windows XP version 5.1 Service Pack 1
> Reporter: Stefan Zoerner
> Assigned To: Alex Karasulu
> Attachments: SearchWithEscapedCharacters.java
>
>
> Searches with escaped characters in the base DN fail. I have created a test entry like this:
> dn: sn=Ferry,dc=example,dc=com
> objectclass: top
> objectclass: person
> sn: Ferry
> cn: Bryan Ferry
> and perform searches with the following parameters
> 1)
> BASE DN: sn=\46\65\72\72\79,dc=example,dc=com
> Filter: (cn=Bryan Ferry)
> Scope: BASE
> 2)
> BASE DN: sn=#4665727279,dc=example,dc=com
> Filter: (cn=Bryan Ferry)
> Scope: BASE
> In both cases the entry is not found, although it should (see examples in Chapter 5 of RFC 2253). In example 1 the search base is the DN of the example with "Ferry" escaped with backslashes. The second example is the same search base, but with the value BER encoded (octet String).
> An attached JUnit test creates the entry and performs both search ops. It passes with Sun Java System Directory Server 5.2 but fails with ApacheDS.
--
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
[jira] Commented: (DIRSERVER-638) Searches with escaped characters
in the base DN fail.
Posted by "Alex Karasulu (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DIRSERVER-638?page=comments#action_12426023 ]
Alex Karasulu commented on DIRSERVER-638:
-----------------------------------------
I was handling this before with DN normalization without issue when we were using the old DN parser. Antlr productions were handling the conversion of these forms into a normalized (canonical value). I'll have to dive into the new normalization code which is hand woven to add this normalization.
> Searches with escaped characters in the base DN fail.
> -----------------------------------------------------
>
> Key: DIRSERVER-638
> URL: http://issues.apache.org/jira/browse/DIRSERVER-638
> Project: Directory ApacheDS
> Issue Type: Bug
> Affects Versions: 1.0-RC3
> Environment: ApacheDS 1.0 RC 3
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_04-b05)
> Microsoft Windows XP version 5.1 Service Pack 1
> Reporter: Stefan Zoerner
> Assigned To: Alex Karasulu
> Attachments: SearchWithEscapedCharacters.java
>
>
> Searches with escaped characters in the base DN fail. I have created a test entry like this:
> dn: sn=Ferry,dc=example,dc=com
> objectclass: top
> objectclass: person
> sn: Ferry
> cn: Bryan Ferry
> and perform searches with the following parameters
> 1)
> BASE DN: sn=\46\65\72\72\79,dc=example,dc=com
> Filter: (cn=Bryan Ferry)
> Scope: BASE
> 2)
> BASE DN: sn=#4665727279,dc=example,dc=com
> Filter: (cn=Bryan Ferry)
> Scope: BASE
> In both cases the entry is not found, although it should (see examples in Chapter 5 of RFC 2253). In example 1 the search base is the DN of the example with "Ferry" escaped with backslashes. The second example is the same search base, but with the value BER encoded (octet String).
> An attached JUnit test creates the entry and performs both search ops. It passes with Sun Java System Directory Server 5.2 but fails with ApacheDS.
--
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
[jira] Assigned: (DIRSERVER-638) Searches with escaped characters
in the base DN fail.
Posted by "Alex Karasulu (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DIRSERVER-638?page=all ]
Alex Karasulu reassigned DIRSERVER-638:
---------------------------------------
Assignee: Alex Karasulu
> Searches with escaped characters in the base DN fail.
> -----------------------------------------------------
>
> Key: DIRSERVER-638
> URL: http://issues.apache.org/jira/browse/DIRSERVER-638
> Project: Directory ApacheDS
> Issue Type: Bug
> Affects Versions: 1.0-RC3
> Environment: ApacheDS 1.0 RC 3
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_04-b05)
> Microsoft Windows XP version 5.1 Service Pack 1
> Reporter: Stefan Zoerner
> Assigned To: Alex Karasulu
> Attachments: SearchWithEscapedCharacters.java
>
>
> Searches with escaped characters in the base DN fail. I have created a test entry like this:
> dn: sn=Ferry,dc=example,dc=com
> objectclass: top
> objectclass: person
> sn: Ferry
> cn: Bryan Ferry
> and perform searches with the following parameters
> 1)
> BASE DN: sn=\46\65\72\72\79,dc=example,dc=com
> Filter: (cn=Bryan Ferry)
> Scope: BASE
> 2)
> BASE DN: sn=#4665727279,dc=example,dc=com
> Filter: (cn=Bryan Ferry)
> Scope: BASE
> In both cases the entry is not found, although it should (see examples in Chapter 5 of RFC 2253). In example 1 the search base is the DN of the example with "Ferry" escaped with backslashes. The second example is the same search base, but with the value BER encoded (octet String).
> An attached JUnit test creates the entry and performs both search ops. It passes with Sun Java System Directory Server 5.2 but fails with ApacheDS.
--
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
[jira] Closed: (DIRSERVER-638) Searches with escaped characters in
the base DN fail.
Posted by "Alex Karasulu (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DIRSERVER-638?page=all ]
Alex Karasulu closed DIRSERVER-638.
-----------------------------------
Fix Version/s: 1.1.0
1.0-RC4
Resolution: Fixed
Sorry E I fixed this one before I read your comment to stop and talk about it. My fixes solve the issues in this test case. All stuff seems to pass. However if you don't like the solution which was on commits: 429140 and 429141 let me know I can roll them back.
Currently this fix only works if the DN value that is escaped is for a String based attribute. If it is binary then the server will bomb out. I'm not so worried about this since it is very very very rare to be using a binary attribute in the DN or the filter assertions.
Let me know what you want to do with this buddy and I can rollback. Again sorry about moving fast on this without consultation. (I figured you were MIA on vacation).
> Searches with escaped characters in the base DN fail.
> -----------------------------------------------------
>
> Key: DIRSERVER-638
> URL: http://issues.apache.org/jira/browse/DIRSERVER-638
> Project: Directory ApacheDS
> Issue Type: Bug
> Affects Versions: 1.0-RC3
> Environment: ApacheDS 1.0 RC 3
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_04-b05)
> Microsoft Windows XP version 5.1 Service Pack 1
> Reporter: Stefan Zoerner
> Assigned To: Alex Karasulu
> Fix For: 1.1.0, 1.0-RC4
>
> Attachments: SearchWithEscapedCharacters.java
>
>
> Searches with escaped characters in the base DN fail. I have created a test entry like this:
> dn: sn=Ferry,dc=example,dc=com
> objectclass: top
> objectclass: person
> sn: Ferry
> cn: Bryan Ferry
> and perform searches with the following parameters
> 1)
> BASE DN: sn=\46\65\72\72\79,dc=example,dc=com
> Filter: (cn=Bryan Ferry)
> Scope: BASE
> 2)
> BASE DN: sn=#4665727279,dc=example,dc=com
> Filter: (cn=Bryan Ferry)
> Scope: BASE
> In both cases the entry is not found, although it should (see examples in Chapter 5 of RFC 2253). In example 1 the search base is the DN of the example with "Ferry" escaped with backslashes. The second example is the same search base, but with the value BER encoded (octet String).
> An attached JUnit test creates the entry and performs both search ops. It passes with Sun Java System Directory Server 5.2 but fails with ApacheDS.
--
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
[jira] Updated: (DIRSERVER-638) Searches with escaped characters in
the base DN fail.
Posted by "Stefan Zoerner (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DIRSERVER-638?page=all ]
Stefan Zoerner updated DIRSERVER-638:
-------------------------------------
Attachment: SearchWithEscapedCharacters.java
JUnit test case with JNDI search ops as described in the issue.
> Searches with escaped characters in the base DN fail.
> -----------------------------------------------------
>
> Key: DIRSERVER-638
> URL: http://issues.apache.org/jira/browse/DIRSERVER-638
> Project: Directory ApacheDS
> Type: Bug
> Versions: 1.0-RC3
> Environment: ApacheDS 1.0 RC 3
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_04-b05)
> Microsoft Windows XP version 5.1 Service Pack 1
> Reporter: Stefan Zoerner
> Attachments: SearchWithEscapedCharacters.java
>
> Searches with escaped characters in the base DN fail. I have created a test entry like this:
> dn: sn=Ferry,dc=example,dc=com
> objectclass: top
> objectclass: person
> sn: Ferry
> cn: Bryan Ferry
> and perform searches with the following parameters
> 1)
> BASE DN: sn=\46\65\72\72\79,dc=example,dc=com
> Filter: (cn=Bryan Ferry)
> Scope: BASE
> 2)
> BASE DN: sn=#4665727279,dc=example,dc=com
> Filter: (cn=Bryan Ferry)
> Scope: BASE
> In both cases the entry is not found, although it should (see examples in Chapter 5 of RFC 2253). In example 1 the search base is the DN of the example with "Ferry" escaped with backslashes. The second example is the same search base, but with the value BER encoded (octet String).
> An attached JUnit test creates the entry and performs both search ops. It passes with Sun Java System Directory Server 5.2 but fails with ApacheDS.
--
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