the problem is within the backend general search, I consider this a bug and not rfe. this is actually a dup of bug#1148797. 2014-12-30 11:42:37,145 INFO [org.ovirt.engine.core.bll.SearchQuery] (http--0.0.0.0-8080-4) [] ResourceManager::searchBusinessObjects - erroneous search text - ''ADUSER: allnames=#alon*'' 2014-12-30 11:42:37,146 INFO [org.ovirt.engine.core.bll.SearchQuery] (http--0.0.0.0-8080-4) [] ResourceManager::searchBusinessObjects - erroneous search text - ''ADGROUP: name=#alon*''
(In reply to Yair Zaslavsky from comment #7) > Alon, for 3.5 (and above) do we want to fix this at general ldap component? > What about backport for older versions? is this required? as I wrote in comment#2, this has nothing to do with extension. something at core is not parsing queries correctly.
According to the LDAP spec, # has a special meaning, as it uses for hex string representations (https://tools.ietf.org/html/rfc4514). I would suggest escaping the # and updating ADSyntaxChecker accordingly (meaning, the user writes \#, and our RegExp is updated accordingly)
(In reply to Liran Zelkha from comment #16) > According to the LDAP spec, # has a special meaning, as it uses for hex > string representations (https://tools.ietf.org/html/rfc4514). > I would suggest escaping the # and updating ADSyntaxChecker accordingly > (meaning, the user writes \#, and our RegExp is updated accordingly) The search should not effect the underline provider consideration. Engine should not assume anything as it does not know what is actually queried (ldap, database, file, etc...).
*** Bug 1148797 has been marked as a duplicate of this bug. ***
Currently escape characters documented in http://www.zytrax.com/books/ldap/apa/search.html are not supported "If you need to search for a pattern that includes a special character (* ) ( \ or NULL) it must be escaped using the format '\code' (the code is actually the 2 hexadecimal characters representing the ASCII character). Similarly any binary value may be search for by using its hexadecimal value." \2a replaces or escapes * \28 replaces or escapes ( \29 replaces or escapes ) \5c replaces or escapes \ If you think this is mandatory, please open a separate BZ for that
(In reply to Eli Mesika from comment #24) > Currently escape characters documented in > http://www.zytrax.com/books/ldap/apa/search.html are not supported > > "If you need to search for a pattern that includes a special character (* ) > ( \ or NULL) it must be escaped using the format '\code' (the code is > actually the 2 hexadecimal characters representing the ASCII character). > Similarly any binary value may be search for by using its hexadecimal value." > > \2a replaces or escapes * > \28 replaces or escapes ( > \29 replaces or escapes ) > \5c replaces or escapes \ > > If you think this is mandatory, please open a separate BZ for that this is done within provider. which provider have you tested with?
(In reply to Alon Bar-Lev from comment #25) > > this is done within provider. > > which provider have you tested with? RHDS
(In reply to Eli Mesika from comment #26) > (In reply to Alon Bar-Lev from comment #25) > > > > this is done within provider. > > > > which provider have you tested with? > > RHDS legacy and unsupported (kerbldap) new and supported (ovirt-engine-extension-aaa-ldap)
ovirt-3.6.0-3 release
i dont see any 3.5 patch attached to the bug, can you add it?
*** Bug 1221302 has been marked as a duplicate of this bug. ***
no, its not in the 3.5.4 branch and should be removed from the errata: https://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=shortlog;h=refs%2Fheads%2Fovirt-engine-3.5.4
removed it from the errata.
Anand - See question on Bug 1148797. If the answer is no, this bug will have to move to 4.0.
Verified with Anand that this is enough to cover the tickets.
setting missing ovirt-3.5.5 milestone for 3.5.5 bugs.