- re-stablishes old behaviour with cache to return null instead of throwing
an InvalidTokenException when the token is cached as non-existing
- token invalidation and re-generation are bundled in a DB transaction now
Signed-off-by: Arthur Schiwon <blizzz@arthur-schiwon.de>
Avoid future collisions for not yet created updater and audit log files (at least using default names).
Signed-off-by: Josh <josh.t.richards@gmail.com>
This is recurrent scenario that we are searching for users and then for
each users we fetch the displayName. This is inefficient, so instead try
to do one query to fetch everything (e.g. Database backend) or use the
already existing DisplayNameCache helper.
Signed-off-by: Carl Schwan <carl@carlschwan.eu>
In OC\User\Manager::createUserFromBackend the newly created user is read
using getUserObject($uid, $backend) but that can cause causal read
issues (wrote in DB primary, not yet in secondary).
In OC\User\Database user backend the user cache is unset after the
insert, so it can't be used by getRealUID() (which is called by
getUserObject()).
To avoid that we make sure the user cache is repopulated in a
transaction.
Signed-off-by: Thomas Citharel <tcit@tcit.fr>
Apps might also like to know about failed logins.
This adds that event.
The private interface changes are backwards compatible so all should be fine.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
The condition of a non-existent login token can happen for concurrent
requests. Admins can not do anything about this. So this is to be
expected to happen occasionally. This event is only bad if none of the
requests is able to re-acquire a session. Luckily this happens rarely.
If a login loop persists an admin can still lower the log level to find
this info. But a default error log level will no longer write those
infos about the failed cookie login of one request.
Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>
- LDAP has an email address with capital letters
- NC store this address in lower case
- When the user logs in, we compare the [stored email with the new lower case email](https://github.com/nextcloud/server/blob/master/lib/private/AllConfig.php#L259-L261) before storing it. Here, both email will be the same, so we won't store the new email address with upper case letters. Which is what we want.
- We then [compare emails as they are before triggering an event](https://github.com/nextcloud/server/blob/master/lib/private/User/User.php#L202-L204), they won't match, so the user will receive an email signaling an email change every time he logs in.
The fix is to compare the old email with the new lower case email before sending the event.
Signed-off-by: Louis Chemineau <louis@chmn.me>
