UniqueConstraintViolationException is no longer throw directly but
instead is now wrapped inside a \OCP\DB\Exception. So check the
exception reason.
Signed-off-by: Carl Schwan <carl.schwan@nextclound.com>
Backends can decide which names they accept for login,
e.g. with user_ldap you can configure arbitrary login fields.
This was a hacky approach to allow login via email,
so instead this is now only handled by the local user backend.
This also fixes some other related problems:
Other logic relys on `backend::get()` which was not handling email,
so e.g. password policy could not block users logged in via email
if they use out-dated passwords.
Similar for other integrations, as the user backend was not consistent with
what is a login name and what not.
Co-authored-by: Ferdinand Thiessen <opensource@fthiessen.de>
Co-authored-by: Côme Chilliet <91878298+come-nc@users.noreply.github.com>
Signed-off-by: Ferdinand Thiessen <opensource@fthiessen.de>
Sessions created during the login flow v2 should be short lived to not leave an unexpected opened session in the browser.
This commit add a property to the session object to track its origin, and will close it as soon as possible, i.e., on the first non public page request.
Signed-off-by: Louis Chemineau <louis@chmn.me>
If a token was already removed from the database but not from the
configuration clearing the tokens will try to remove it again from the
database, which caused a DoesNotExistException to be thrown.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Otherwise as the tokens were removed from the database but not from the
configuration the next time that the tokens were cleared the previous
tokens were still got from the configuration, and trying to remove them
again from the database ended in a DoesNotExistException being thrown.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Currently there is a problem if an exception is thrown in `User::delete`,
because at that point the user is already removed from the backend,
but not all data is deleted.
There is no way to recover from this state, as the user is gone no information is available anymore.
This means the data is still available on the server but can not removed by any API anymore.
The solution here is to first set a flag and backup the user home,
this can be used to recover failed user deletions in a way the delete can be re-tried.
Signed-off-by: Ferdinand Thiessen <opensource@fthiessen.de>
Require user verification if all tokens are registered
with UV flag, else discourage it
Signed-off-by: S1m <git@sgougeon.fr>
Signed-off-by: Richard Steinmetz <richard@steinmetz.cloud>
- 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>
SSO backends like SAML and OIDC tried a trick to suppress password
confirmations as they are not possible by design. At least for SAML it was
not reliable when existing user backends where used as user repositories.
Now we are setting a special scope with the token, and also make sure that
the scope is taken over when tokens are regenerated.
Signed-off-by: Arthur Schiwon <blizzz@arthur-schiwon.de>
