Issue Details (XML | Word | Printable)

Key: DIRSERVER-389
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Alex Karasulu
Reporter: Stefan Zoerner
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
Directory ApacheDS

Search filters with wrong case in attribute names lead to wrong result

Created: 26/Oct/05 06:49 AM   Updated: 10/Feb/06 12:34 PM
Return to search
Component/s: None
Affects Version/s: None
Fix Version/s: None

Time Tracking:
Not Specified

Resolution Date: 26/Oct/05 12:35 PM


 Description  « Hide
Search filters which use attribute names with "wrong" case cause the search operation to return nothing. Example:

$ ldapsearch -D "uid=admin,ou=system" -w ***** -p 10389 -b "dc=apache,dc=org" -s base "(Objectclass=*)"
(nothing)
$

But the following still works as expected:

$ ldapsearch -D "uid=admin,ou=system" -w secret -p 10389 -b "dc=apache,dc=org" -s base "(objectClass=*)"
dc=apache,dc=org
dc=apache
objectClass=extensibleObject
objectClass=domain
objectClass=top

I assume the error is due to changes in class NormalizationService (package org.apache.ldap.server.normalization) done to fix DIREVE-274, because if "wrong" attributes are used, this interceptor raises WARN messages like

[23:37:27] WARN [org.apache.ldap.server.normalization.NormalizationService] - undefined filter based on undefined attributeType 'Objectclass' not evaluated at all. Returning empty enumeration.

which explains the behavior above.

Btw.: The behavior causes Softerra LDAP Administrator 3.2.1 to fail during the exploration of entries. This is how I found it.


 All   Comments   Work Log   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Repository Revision Date User Message
ASF #328545 Wed Oct 26 03:34:27 UTC 2005 akarasulu changes ...

 o OID registry did not perform normalized lookups with hasOid() so I added that
   and everything worked fine. What worried me is why this popped up now. I
   can only attribute it to new code executing for the first time.

 This fixes DIREVE-294.
Files Changed
MODIFY /directory/apacheds/trunk/main/src/test/org/apache/ldap/server/MiscTest.java
MODIFY /directory/apacheds/trunk/core/src/main/java/org/apache/ldap/server/normalization/NormalizationService.java
MODIFY /directory/apacheds/trunk/core/src/main/java/org/apache/ldap/server/schema/GlobalOidRegistry.java
MODIFY /directory/apacheds/trunk/core/src/main/java/org/apache/ldap/server/schema/GlobalAttributeTypeRegistry.java
MODIFY /directory/apacheds/trunk/core/src/main/java/org/apache/ldap/server/schema/bootstrap/BootstrapOidRegistry.java
MODIFY /directory/apacheds/trunk/xdocs/users/index.xml

Repository Revision Date User Message
ASF #328604 Wed Oct 26 09:12:14 UTC 2005 szoerner Added a new test case for search ops to cover the situtaion described in DIREVE-294.
Files Changed
MODIFY /directory/testsuite/trunk/ldaptests/src/main/java/org/apache/ldap/testsuite/ldaptests/jndi/ops/search/AllTests.java
ADD /directory/testsuite/trunk/ldaptests/src/main/java/org/apache/ldap/testsuite/ldaptests/jndi/ops/search/SearchFilterAttributeNamesTest.java

Alex Karasulu added a comment - 26/Oct/05 12:35 PM
Committed fix in revision 328545 here:

http://svn.apache.org/viewcvs.cgi?rev=328545&view=rev

Alex Karasulu made changes - 26/Oct/05 12:35 PM
Field Original Value New Value
Status Open [ 1 ] Resolved [ 5 ]
Resolution Fixed [ 1 ]
Alex Karasulu added a comment - 26/Oct/05 12:37 PM
I am really sorry about this screw up. It was a bug deep in the BootstrapOidRegistry that caused this. For some reason I think this was the first time we triggered the execution of the code this way. Anyhow its fix and I appologize for any runaround this may have caused you.

Stefan Zoerner added a comment - 26/Oct/05 06:41 PM
I have rebuilt the server and retested this one with a new test case in the test suite here:
http://svn.apache.org/viewcvs.cgi?rev=328604&view=rev
and with Softerra LDAP Administrator (defect was first observed there) as well.
It works as expected now.

I use the Softerra tool, which uses the "(Objectclass=*)" filter for expanding the tree as I learned yesterday, daily with our server. I would have noticed it immediately if the defect has been present before the latest bug fixing changes.

Anyway, thanks for fixing it at once, Alex! Our Softerra users would have hated us for the 0.9.3 release with this defect. It was not possible to browse the directory tree at all.

Now me exploring Apache Directory Server with this GUI client happy again close this issue.

Stefan Zoerner made changes - 26/Oct/05 06:41 PM
Status Resolved [ 5 ] Closed [ 6 ]
Alex Karasulu made changes - 10/Feb/06 12:34 PM
Fix Version/s 0.9.3 [ 12310193 ]
Project Directory Server [ 10516 ] Directory ApacheDS [ 12310260 ]
Key DIREVE-294 DIRSERVER-389