Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>Although I'm not familiar with Spring LDAP, it doesn't sound like there's necessarily a reason to be concerned. LDAP filters aren't transmitted as clear text, but rather in a binary encoding, and there is no need for escaping in this mechanism (nor would it be correct to do so).</p> <p>Let's take "(sAMAccountName=boi*)" as an example. As written, this filter is a substring filter with a subInitial component of "boi". As you point out, if you want it to be an equality filter rather than a substring filter, then the string representation would have to be "(sAMAccountName=boi\2a)". However, the binary encodings for these filters don't use any escaping, but instead use an ASN.1 BER type to differentiate between substring and equality filters.</p> <p>If you want "(sAMAccountName=boi*)" as a substring filter, then the encoded representation would be:</p> <pre><code> a417040e73414d4163636f756e744e616d6530058003626f69 </code></pre> <p>On the other hand, if you want "(sAMAccountName=boi\2a)" as an equality filter, the encoding would be:</p> <pre><code> a316040e73414d4163636f756e744e616d650404626f692a </code></pre> <p>The full explanation of the encoding isn't something I want to get into, but the "a4" at the beginning of the first one indicates that it's a substring filter, whereas the "a3" at the beginning of the second indicates that it's an equality filter.</p> <p>You should be able to verify the actual bytes sent in WireShark. It may well be that WireShark doesn't properly escape the filter when generating the string representation, but that would be an issue with WireShark itself. The directory server only gets the binary representation, and it's hard to believe that an LDAP server would misinterpret that.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload