[
https://issues.apache.org/jira/browse/DIRSTUDIO-1078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15046041#comment-15046041
]
Emmanuel Lecharny commented on DIRSTUDIO-1078:
----------------------------------------------
Hmmm...
We have a double un-escaping occuring. Let's see how it goes, from the inside.
We have a DN which RDN has a value with a starting '#'. In this case, RFC 4514
commands that the '# is escaped :
{noformat}
attributeTypeAndValue = attributeType EQUALS attributeValue
attributeType = descr / numericoid
attributeValue = string / hexstring
string = [ ( leadchar / pair ) [ *( stringchar / pair ) ( trailchar /
pair ) ] ]
leadchar = LUTF1 / UTFMB
LUTF1 = %x01-1F / %x21 / %x24-2A / %x2D-3A /
%x3D / %x3F-5B / %x5D-7F
pair = ESC ( ESC / special / hexpair )
special = escaped / SPACE / SHARP / EQUALS
escaped = DQUOTE / PLUS / COMMA / SEMI / LANGLE / RANGLE
{noformat}
For {{cn=#Some...}}, this means we will have to write the DN as
{{cn=\#Some...}} or {{cn=\23Some...}}.
Now, RFC 4515 says that filters may have escaped sequences :
{noformat}
simple = attr filtertype assertionvalue
filtertype = equal / approx / greaterorequal / lessorequal
equal = EQUALS
assertionvalue = valueencoding
valueencoding = 0*(normal / escaped)
normal = UTF1SUBSET / UTFMB
escaped = ESC HEX HEX
UTF1SUBSET = %x01-27 / %x2B-5B / %x5D-7F
{noformat}
which means that when we meet a '\' char in the filter (ESC), it will be
followed by two hexadecimal values. In our case, if the filter is
{{cn=\23Some...}}, then the \23 will be translated to '#', leading to a wrong
DN when passed to the server. If the filter is {{cn=\#Some...}}, then the
filter will not be accepted because # is not an hexadecimal value...
So the solution would be to escape the escape and to use a hexadecimal value
for the # : {{cn=\5C23Some...}}. Here; \5C encode for \, which transforms the
filter to {{cn=\23Some...}}, and when the DN is analysed it's transformed to
{{cn=#Some...}}.
I have tested such a filter : {{cn=\5C23Some...}}, and it gets back the
expected entry.
At the end of the day, we are not overdoing, we are just quite strict with the
syntax of filters and DN.
Can you give a try to a search done with such a filter :
{noformat}
(&
(objectClass=group)
(displayName=*)
(|
(memberOf:1.2.840.113556.1.4.1941:=CN=\5C23OME,OU=Groups,OU=EMEA,DC=example,DC=net)
)
)
{noformat}
?
> unable to use # pound hash sign in LDAP filters
> -----------------------------------------------
>
> Key: DIRSTUDIO-1078
> URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1078
> Project: Directory Studio
> Issue Type: Bug
> Affects Versions: 2.0.0-M9 (2.0.0.v20150606-M9)
> Reporter: Sorin Sbarnea
>
> It seems impossible to perform searches that to use # sign inside. Tried to
> add them, not escaped, escaped with single or double backslash but none of
> these approaches worked.
> Example
> {code}
> (&(objectClass=group)(displayName=*)(|(memberOf:1.2.840.113556.1.4.1941:=CN=\\#SOME,OU=Groups,OU=EMEA,DC=example,DC=net)))
> (&(objectClass=group)(displayName=*)(|(memberOf:1.2.840.113556.1.4.1941:=CN=\#SOME,OU=Groups,OU=EMEA,DC=example,DC=net)))
> (&(objectClass=group)(displayName=*)(|(memberOf:1.2.840.113556.1.4.1941:=CN=#SOME,OU=Groups,OU=EMEA,DC=example,DC=net)))
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
