LDAP searches can return weird matches based on an ID match

[sdwilsh]

Describe the bug

LDAP group searches (performed when trying to add a new member to a space, for instance) do a substring search for both the cn and the entryUUID. This leads to weird experiences where results are returned that do not match the query in an obvious way.

Steps to reproduce

1. Have a group with an entryUUID that contains a string such as "beef" in it. This might be difficult because these are generated by the LDAP provider.
2. Try to add "Beef Tobin" to a space

Expected behavior

Only see an entry with a name that contains "beef" (a person named Beef Tobin)

Actual behavior

See an entry that does not contain "beef" for the group that has the entryUUID with the substring "beef".

Additional context

This came up when I discovered I couldn't add someone to a Space. After some debugging, it turned out that my LDAP provider (lldap, which isn't uncommon for self-hosters to run) did not support substring queries on entryUUID, and so the LDAP query failed. I filed an issue there to add that support, but they rightly pushed back that the behavior is odd.

I think it's reasonable to match an an exact entryUUID hit in LDAP so power users/admins can get the exact group they want if they know it, but it can be jarring and produce unexpected results to end users since searches start with as few as three characters.

[sdwilsh]

I have a fix for this in sdwilsh@451a481 that I can submit as a PR if it's agreed this behavior change is something that is wanted.

[micbar]

Question: how do you get strings into your entryuuid? That should always be a uuid.

[sdwilsh]

It is generated by the ldap backend (as required by RFC 4530), and I don't control it. Nothing I've described in this issue implies that entryUUID isn't a uuid; "beef" is within the allowed alphabet of a uuid (as defined in RFC 9562).

[rhafer]

Actually OpenLDAP also doesn't support substring filters for entryUUID. And that is ok. We're current using an OR filter like this (|(cn=*beef*)(entryUUID=*beef*)) the (entryUUID=*beef*) evaluates to undefined because entryUUID doesn't have a substringMatch defined. And for an OR filter that bascially means it is being ignored. And entries that match the other part of the OR filter are return (https://datatracker.ietf.org/doc/html/rfc4511#section-4.5.1.7)

But you're right the filter doesn't really make much sense for searching groups. The (entryUUID=*something*) will always be undefined and search groups by their UUID also doesn't really make much sense in this context.

[sdwilsh]

Actually OpenLDAP also doesn't support substring filters for entryUUID. And that is ok.

Interestingly, for LLDAP, the query errors, and it breaks the UI (no autocomplete) when trying to add people to spaces (and possibly in other areas, but I haven't tried anything else).

@rhafer, if sdwilsh@451a481 looks like the right approach, I can submit a PR for this. This is my first-ever time writing Go, so I /think/ I'm doing the right thing (tests pass), but not very confident about that.

[rhafer]

@rhafer, if sdwilsh@451a481 looks like the right approach, I can submit a PR for this

A PR would be greatly appreciated. But I think the correct fix it to just not include the id in the filter at all. So really just use a substring filter on the name and nothing else.