Make the database user backend cache case insensitive like the DB table

[MorrisJobke]

Database users are already fetched from the database via the uid_lower column, but the cache is built using the cased version of the UID. That might lead to non-matches in case the casing is not the same. This change only touches the index of the in memory cache.

This was noticed in following case:

• having a Nextcloud instance and provision users with cased UID via the provisioning API (like "Hermes")
• now use the instance as normal with the user "Hermes"
• configure user_saml having a identity provider that sends the user ID in lower case and has autoprovisioning enabled to add new users automatically if they haven't been registered before
• the goal is that the users still see their files and shares

Problem:

• the users are not found in the user database backend and are auto provisioned in the user saml backend
• provision the users with the lower casing via API is not possible because the database user backend is constrained by the lower case version but does not properly return the user as the cache is not filled in the same way users are fetched

I tested this with existing users and incoming/outgoing shares.

[PVince81]

👍

[blizzz]

strtolower should be enough, since Database complies with rules and does not allow non-ascii characters in the user id.

I am afraid you may run into issues in setups where you have mixed-case type usernames. It is disconcerting that database backend would be fickle with user ids which should be exactly what they are, without variations (they are okay for login names).

[MorrisJobke]

I am afraid you may run into issues in setups where you have mixed-case type usernames. It is disconcerting that database backend would be fickle with user ids which should be exactly what they are, without variations (they are okay for login names).

That's the reason I only changed the index of the cache. The database already provides the same set of users because there is a unique index on the uid_lower there could only be one variant in the database anyways. And as this only affects the database user backend it does not collide with other backends. Or do I miss something?

[blizzz]

I am afraid you may run into issues in setups where you have mixed-case type usernames. It is disconcerting that database backend would be fickle with user ids which should be exactly what they are, without variations (they are okay for login names).

That's the reason I only changed the index of the cache. The database already provides the same set of users because there is a unique index on the uid_lower there could only be one variant in the database anyways. And as this only affects the database user backend it does not collide with other backends. Or do I miss something?

If it has effects to the outside, then it may collide. And that's what it is all about, is it not? When i run $userManager->getUser('Alice') I do not expect to receive 'alice' and vice versa. As I read the code, when you have user 'Alice' locally and 'alice' on a different backend, the db backend would always return 'Alice' for 'alice'. Or do I interpret things wrongly?

Another (existing!) issue I see is the implementation of loginName2UserName() because in its implementation the login name is treated as user id while it may vary in casing. With your changes it would actually work, but leaves ↑

[MorrisJobke]

If it has effects to the outside, then it may collide. And that's what it is all about, is it not? When i run $userManager->getUser('Alice') I do not expect to receive 'alice' and vice versa. As I read the code, when you have user 'Alice' locally and 'alice' on a different backend, the db backend would always return 'Alice' for 'alice'. Or do I interpret things wrongly?

RIght ... but is this really what was intented here? because it doesn't make sense to search case insensitive, also return it from the DB and then only take it if it really matches the case. Because then you can also just search case sensitive and drop the uid_lower completely. Otherwise it would not make sense at all. 🙈

[blizzz]

I think the lower_uid was mostly to have case-insensitive login names for the local users. and becaue of this it was blocking alterning user ids.