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>
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>
This can happen when the auth.storeCryptedPassword config is used,
which previously errored with:
Hasher::verify(): Argument #2 ($hash) must be of type string, null given
Signed-off-by: Joas Schilling <coding@schilljs.com>
If basic auth is used on WebDAV endpoints, we will not setup a session
by default but instead set a test cookie. Clients which handle session
cookies properly will send back the cookie then on the second request
and a session will be initialized which can be resued for
authentication.
Signed-off-by: Julius Härtl <jus@bitgrid.net>
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 session token renewal does
1) Read the old token
2) Write a new token
3) Delete the old token
If two processes succeed to read the old token there can be two new tokens because
the queries were not run in a transaction. This is particularly problematic on
clustered DBs where 1) would go to a read node and 2) and 3) go to a write node.
Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>
This is an helpful helper that should be used in more place than just
server and this is already the case with groupfodlers, deck, user_oidc
and more using it, so let's make it public
Signed-off-by: Carl Schwan <carl@carlschwan.eu>
For passwords bigger than 250 characters, use a bigger key since the
performance impact is minor (around one second to encrypt the password).
For passwords bigger than 470 characters, give up earlier and throw
exeception recommanding admin to either enable the previously enabled
configuration or use smaller passwords.
Signed-off-by: Carl Schwan <carl@carlschwan.eu>
This adds an option to disable storing passwords in the database. This
might be desirable when using single use token as passwords or very
large passwords.
Signed-off-by: Carl Schwan <carl@carlschwan.eu>
otherwise, when using object store, we loose track of which files the user owns before we can delete them
Signed-off-by: Robin Appelman <robin@icewind.nl>
