-
-
Notifications
You must be signed in to change notification settings - Fork 4.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Prepend wildcard to the LDAP search term #14845
Conversation
It makes the LDAP user/group search behaves consistently with database backend See https://github.com/nextcloud/server/blob/3f4941e48aead48bacc7077e2819b492d1394778/lib/private/Group/Database.php#L270-L274 Signed-off-by: Rémi Alvergnat <remi.alvergnat@gfi.fr>
6446604
to
e8ecddd
Compare
Where are functional tests behaviors implemented ? I can't find them. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 ? |
@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. |
Could this feature be optional by configuration ? |
@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. |
In our use case, groups are prefixed in LDAP with some stuff that categories the groups, separated by semicolons.
But we need those kind of groups to be returned with search input like |
@Toilal don't you have an attribute on the groups that contains the name without those prefixes? |
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. |
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. |
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. On an other side this behaviour can't be configurable and by default disabled ? |
@blizzz Mind to reply here? |
@MorrisJobke thanks for bringing it to my attention again.
@jgribonvald this we can do, although I am not fan of adding more switches and code paths. I would accept it however. |
Thanks @blizzz. |
so the actual use cases are only for groups then, right? We would only need it there. |
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. |
I moved the milestone to 18 since we're in feature freeze. |
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). |
Moved to 20, @Toilal are still in for it? Otherwise I'd say let's close it. Someone else can pick it up still.
Yes, I think this is your setup :)
Perhaps you can make your LDAP behave there similarly, too? That's more save than have a feeling-lucky asterisk up front in general. |
As there was no feedback on this I will close it for now. It can be picked up at any time. |
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