directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Emmanuel Lecharny (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DIRSTUDIO-1078) unable to use # pound hash sign in LDAP filters
Date Tue, 08 Dec 2015 00:21:11 GMT

    [ 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)

Mime
View raw message