Uh oh!
There was an error while loading. Please reload this page.
Fix Ldap search for attributes with no substr matching rule - #32499
Conversation
come-nc
commented
May 23, 2022
It’s not limited to entryUUID it’s any field without a substr matching rule. |
5f6fab5 to
666ec01Comparejulien-nc
commented
May 23, 2022
@come-nc Much better indeed! |
julien-nc
commented
May 31, 2022
blizzz
commented
May 31, 2022
Do we know whether this might have performance impact? I would assume not, but then I know those products and I would not be surprised… |
julien-nc
commented
Jun 2, 2022
@blizzz I have no idea but I think the partial search we do anyway might be way more costly than the additional exact search. |
blizzz
commented
Jun 2, 2022
Certainly. What I wonder is whether the products handle this now smartly, or whether this has an additional performace penalty. For sure we cannot go without the appended wildcard for ordinary searches. An alternative would be a list of known attributes for which we do not add the wildcard. But, if this approach works out fine it is preferable – looks duplicated, but less complex. |
come-nc
commented
Jun 2, 2022
I think techincally you could query the ldap server for schema information to know which fields have substr matching rules and which have not. But that seems overkill for current situation. |
blizzz
commented
Apr 13, 2023
/rebase |
…s without a substr matching rule Signed-off-by: Julien Veyssier <eneiluj@posteo.net>
666ec01 to
f3cd559Compare
Wildcards are not supported when used in search filters for the
entryUUIDattribute. I guess it's the same for some other attributes as well.IMO we can make an exact search filter in this case.
Is there a cleaner way to address that issue?