While technically they are stored the same. This session variable is
used to indicate that a user is using an app password to authenticate.
Like from a client. Or when having it generated automatically.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
even when token is invalid or has no password.
Returning the uid as loginname is wrong, and leads to problems when
these differ. E.g. the getapppassword API was creating app token with
the uid as loginname. In a scenario with external authentication (such
as LDAP), these tokens were then invalidated next time their underlying
password was checked, and systematically ceased to function.
Co-authored-by: kesselb <mail@danielkesselberg.de>
for: switch to consistent camelCase
Signed-off-by: Lionel Elie Mamane <lionel@mamane.lu>
To continue this formatting madness, here's a tiny patch that adds
unified formatting for control structures like if and loops as well as
classes, their methods and anonymous functions. This basically forces
the constructs to start on the same line. This is not exactly what PSR2
wants, but I think we can have a few exceptions with "our" style. The
starting of braces on the same line is pracrically standard for our
code.
This also removes and empty lines from method/function bodies at the
beginning and end.
Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>
Avoids directly getting the token again. We just inserted it so it and
have all the info. So that query is just a waste.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
Fixes#12498
This means that we set that it is a proper app token once it is
validated. This will allow the 2FA middleware to just run the same
check.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
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>
* 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>
* 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>
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>
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>
* Add postLogout hook to finish sessions from external session managers like CAS
* Add postLogout hook to finish sessions from external session managers like CAS
Signed-off-by: Morris Jobke <hey@morrisjobke.de>
Christoph Wurst
Morris Jobke
Roeland Jago Douma
Lionel Elie Mamane
Greta Doci
Arthur Schiwon
Lukas Reschke
Robin Appelman
Felix Rupp
Joas Schilling