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