Fixes#12131
If we hit an expired token there is no need to continue checking. Since
we know it is a token.
We also should not register this with the bruteforce throttler as it is
actually a valid token. Just expired. Instead the authentication should
fail. And buisness continues as usual.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
Fixes#11097
If your password hash changed (becuse your are on 7.2 and we moved to
ARGON2). Then we shold not 'set a new password' but just update the
hash. As else we invoke the password policy again which might lock out
users.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
* On weblogin check if we have invalid public key tokens
* If so update them all with the new token
This ensures that your marked as invalid tokens work again if you once
login on the web.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
This protects our cookies a bit more. It makes sure that when a 3rdparty
websites embededs a public alendar for example. That all the users see
this in anonymous mode there.
It adds a small helper function.
In the future we can think about protecting other cookies like this as
well. But for now this is sufficient to not have the user logged in at
all when doing 3rdparty requests.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
Sometimes when we force a session regeneration we want to update the
current token for this session.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
Fixes#9279
If a pure numerical user is in the DB the value might be casted to a int
when returned. Cast it all to a string so we don't break the strict
typing.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
Due to a misplaced closing parenthesis the condition of the left join
clause was just "userid = uid"; the other conditions were passed as
additional parameters to "leftJoin", and thus they were ignored.
Therefore, the result set contained every preference of each user
instead of only the email, so the "WHERE configvalue LIKE XXX" matched
any configuration value of the user.
Besides the closing parenthesis this commit also fixes the literal
values. Although "Literal" objects represent literal values they must be
created through "IExpressionBuilder::literal()" to be properly quoted;
otherwise it is just a plain string, which is treated as a column name.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
* We first try the email as username but this fails
* Then we get the uid from the email and try again
We should not log the first attempt since it polutes the log with failed
login attempts while the login actually is valid.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
Fixes#7175.
- Updated the query to fetch the users in users > everyone tab.
- Updated the query to fetch the users in users > admin tab.
- Tested to ensure that the disabled users are also being fetched.
- Added test cases.
Signed-off-by: Abijeet <abijeetpatro@gmail.com>
The CSP nonce is based on the CSRF token. This token does not change,
unless you log in (or out). In case of the session data being lost,
e.g. because php gets rid of old sessions, a new CSRF token is gen-
erated. While this is fine in theory, it actually caused some annoying
problems where the browser restored a tab and Nextcloud js was blocked
due to an outdated nonce.
The main problem here is that, while processing the request, we write
out security headers relatively early. At that point the CSRF token
is known/generated and transformed into a CSP nonce. During this request,
however, we also log the user in because the session information was
lost. At that point we also refresh the CSRF token, which eventually
causes the browser to block any scripts as the nonce in the header
does not match the one which is used to include scripts.
This patch adds a flag to indicate whether the CSRF token should be
refreshed or not. It is assumed that refreshing is only necessary
if we want to re-generate the session id too. To my knowledge, this
case only happens on fresh logins, not when we recover from a deleted
session file.
Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>
`\OC\User\Database::createUser` can throw a PHP exception in case the UID is longer than
permitted in the database. This is against it's PHPDocs and we should cast this to `false`,
so that the regular error handling triggers in.
The easiest way to reproduce is on MySQL:
1. Create user `aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa` in admin panel
2. Create user `aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa` in admin panel again
3. See SQL exception as error message
Signed-off-by: Lukas Reschke <lukas@statuscode.ch>
Most of the time, when people have multiple backends or add a
custom backend, they want to create the users there and not in
the default backend. But since that is registered first, users
were always created there.
Signed-off-by: Joas Schilling <coding@schilljs.com>
The encryption app relies on the post_login hook to initialize its keys.
Since we do not emit it on a remembered login, the keys were always un-
initialized and the user was asked to log out and in again.
This patch *translates* the postRememberedLogin hook to a post_login
hook.
Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>
