Check proper case for user UID

[skjnldsv]

Fix#9532

Testing:
$.get('/ocs/v2.php/cloud/users/admin') 200
$.get('/ocs/v2.php/cloud/users/Admin') 404

[rullzer]

Nope!

This is not the way to go. A lot of things will do 💥. (like people that use case insentivie login from the desktop or android client).

The loginname is case insensitive on our database backend.

[skjnldsv]

The loginname is case insensitive on our database backend.

I never knew! :o

Well, I don't see any other proper way to do it. Adding a check on every userExists function in the provisioning api seems like a terrible way to implement such verification. :/

[rullzer]

Well then the provisioningAPI will just return non sensible data if you don't case the userid correctly. Better than the alternative now ;)

[skjnldsv]

@rullzer our current backend return the uid we request, so there is no way to check if getUID === requestedUID since it will always be true.
Our cache is populated that way :/

[codecov]

Codecov Report

Merging #9633 into master will increase coverage by <.01%.
The diff coverage is 100%.

@@ Coverage Diff @@## master #9633 +/- ##
===========================================
+ Coverage 51.7% 51.7% +<.01% - Complexity 25706 25707 +1 
===========================================
Files 1635 1635 Lines 95957 95960 +3 Branches 1384 1384 ===========================================
+ Hits 49611 49613 +2 - Misses 46346 46347 +1

Impacted Files	Coverage Δ	Complexity Δ
lib/private/User/Database.php	79.22% <100%> (-0.25%)	44 <0> (+1)

[rullzer]

@skjnldsv k let me think if there is a solutoion. But this is not it ;)

[blizzz]

loadUser is called from userExists and getDisplayName. Both expect the current uid. Auth goes via checkpassword, which is and stays case insensitive.

[rullzer]

@blizzz mmmm that might be true... lets see.

[rullzer]

Ok we should do some extensive testing here to make sure it keeps working.

[skjnldsv]

Well, we already know that with this patch, we can create 'test0' and Test0' users.
So we need an extensive testing here as well :)

Maybe keep the non sensitive case check on the userExists check?

[blizzz]

one valid case that @rullzer described: the local backend uses it when creating users, it would still need to make sure that the user id is not taken. what createuser does not do however: asking the User Managers userExists to check against other user backends.

Suggestion: we could phase out userExists, point towards getUser('uid') as a test for existence, and introduce a isUserIDReserved or something like that for user backends to see whether they can give away that one.

#9633 (comment)

[skjnldsv]

@blizzz@rullzer don't forget about this please :D

[MorrisJobke]

@rullzer@nickvergessen Mind to review?

[MorrisJobke]

Most likely nothing for 14 -> moving to 15.

[MorrisJobke]

I guess we need to move this to 16 😢

[skjnldsv]

I'm guessing we can close @MorrisJobke