Prepend wildcard to the LDAP search term

[Toilal]

It makes the LDAP user/group search behaves consistently with database backend

See

server/lib/private/Group/Database.php

Lines 270 to 274 in 3f4941e

	if ($search !== '') {
	$query->where($query->expr()->iLike('gid', $query->createNamedParameter(
	'%' . $this->dbConn->escapeLikeParameter($search) . '%'
	)));
	}

[Toilal]

Where are functional tests behaviors implemented ? I can't find them.

[blizzz]

this kills performance on halfway big LDAP setups as indices cannot work.

[Toilal]

this kills performance on halfway big LDAP setups as indices cannot work.

I don't know how to mitigate this performance issue, I'm a beginner with LDAP, but functionally speaking it's a problem that LDAP filtering and SQL filtering doesn't behave the same way.

Could you tell me why indices may not work with this change ?

[blizzz]

@Toilal Since the start of the string is unknown, the whole index has to be gone from top to bottom as anything can match. That's the reason why it is, as it is. The local user management is not intended for a big number of users.

[jgribonvald]

Could this feature be optional by configuration ?
Like that it permits to each one to make his choice ?

[blizzz]

@jgorgulho@Toilal let's take a step back: What do you need it for? I would doubt it is common only to look at a part of a first, or second name. For the local backend it makes sense, because first and last names are not split, but this is totally doable in LDAP.

[Toilal]

In our use case, groups are prefixed in LDAP with some stuff that categories the groups, separated by semicolons.

esco:Applications:Folios:DE L IROISE_0290009C

But we need those kind of groups to be returned with search input like IROISE.

[blizzz]

@Toilal don't you have an attribute on the groups that contains the name without those prefixes?

[jgribonvald]

No there isn't a such attribute as the unique names depends on the complete name. Also the tree representation (the complete name) is needed to find the rigth group.

[blizzz]

Also the tree representation (the complete name) is needed to find the rigth group.

Sorry, could you rephrase it? Do you refer to the DN?

Imho it makes sense in general to have an attribute that just carries the plain name, which can then be added to the group search attributes (and you can add an index to your LDAP server). Having the wildcard prepended just kills performance for everybody.

[jgribonvald]

We are managing around 45 000 groups, and the representation/structuring of all theses groups is like a tree. But in our ldap all these groups are at the same level and the name is the whole path in the tree (like root:node1:subnode0:sub-subnodeA:leaf). So we consider that the name is the display name like the CN and also the DN is CN + LDAP branch information.
We can't have a display name that will mean something based on the leaf of the tree group (so the tail part) as it can be found several times (when I say several time it will be more than a dozen times). So to show groups to users we need to provide them the whole path else they won't be able to find the rigth group.
Also users won't make search on the whole path as only the last parts of the cn will be used.
The LDAP search in our LDAP is really efficient with wilcard prepended (as we have an index on the cn) so I don't understand why we can't have this behaviour.

On an other side this behaviour can't be configurable and by default disabled ?

[MorrisJobke]

@blizzz Mind to reply here?

[blizzz]

@MorrisJobke thanks for bringing it to my attention again.

On an other side this behaviour can't be configurable and by default disabled ?

@jgribonvald this we can do, although I am not fan of adding more switches and code paths. I would accept it however.

[jgribonvald]

Thanks @blizzz.

[DanScharon]

so the actual use cases are only for groups then, right? We would only need it there.

[blizzz]

Somewhere else someone has had also use cases with a number of and order of names. So in its entirety there a cases for both users and groups.

[blizzz]

I moved the milestone to 18 since we're in feature freeze.

[DanScharon]

Somewhere else someone has had also use cases with a number of and order of names. So in its entirety there a cases for both users and groups.

hmm, interesting. When searching for users from LDAP, substring match already works (at least in our setup). So if I am looking for Mr. Miller I can find him by entering "iller". That doesn't work for groups. So in our case we would only need it for groups and can't say for sure what the performance impact on our LDAP search for users would be (~ 19.000 accounts).

[blizzz]

Moved to 20, @Toilal are still in for it? Otherwise I'd say let's close it. Someone else can pick it up still.

hmm, interesting. When searching for users from LDAP, substring match already works (at least in our setup). So if I am looking for Mr. Miller I can find him by entering "iller".

Yes, I think this is your setup :)

That doesn't work for groups. So in our case we would only need it for groups and can't say for sure what the performance impact on our LDAP search for users would be (~ 19.000 accounts).

Perhaps you can make your LDAP behave there similarly, too? That's more save than have a feeling-lucky asterisk up front in general.

[MorrisJobke]

Moved to 20, @Toilal are still in for it? Otherwise I'd say let's close it. Someone else can pick it up still.

As there was no feedback on this I will close it for now. It can be picked up at any time.