More authrequest fixes

[dani-garcia]

We were checking the user uuid against the authrequest uuid, which would always fail and error out.

Fixes #5174

I've also noticed that we were rotating the user password hash when login in with auth request (where instead of the password, a randomly generated access code is used), this could lead to inoperable accounts.

Also tried to delete the auth requests after they were used or denied, rather than waiting for the timer to clear them up.

[nulano]

I've also noticed that we were rotating the user password hash when login in with auth request (where instead of the password, a randomly generated access code is used), this could lead to inoperable accounts.

Could that have caused #4908?

[BlackDex]

@nulano that was my first thought too when i discussed this with @dani-garcia.
So that might very well could have been the culprit.

[dani-garcia]

It's unlikely, as for that to happen a lot of things would need to be happening at once, but it's definitely possible:

• A user would need to login for the first time since the server changed the password iterations option. This can happen two ways, either the server owner changed the option, or the server got updated to version 1.28+ (which is a year old)
• That initial login needs to be done using the login with device functionality

[nulano]

I no longer recall the details very well, but I feel like those conditions could have been met in my case, so I think this very well could have been what caused my issue.

I had done a large upgrade a short time before, and was logging in on a computer I don't usually use, but I most likely used login with device to do it.

[BlackDex]

Yes, and since those conditions were so unlikely to happen, we never encountered those our self and also were not able to reproduce this in any sane way.