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>
The auth token activity logic works as follows
* Read auth token
* Compare last activity time stamp to current time
* Update auth token activity if it's older than x seconds
This works fine in isolation but with concurrency that means that
occasionally the same token is read simultaneously by two processes and
both of these processes will trigger an update of the same row.
Affectively the second update doesn't add much value. It might set the
time stamp to the exact same time stamp or one a few seconds later. But
the last activity is no precise science, we don't need this accuracy.
This patch changes the UPDATE query to include the expected value in a
comparison with the current data. This results in an affected row when
the data in the DB still has an old time stamp, but won't affect a row
if the time stamp is (nearly) up to date.
This is a micro optimization and will possibly not show any significant
performance improvement. Yet in setups with a DB cluster it means that
the write node has to send fewer changes to the read nodes due to the
lower number of actual changes.
Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>
For historic reasons we couldn't add a nullable type hint before
nullable type hints were supported by our target php versions. This is
now possible.
Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>
Else you can end up that you renewed your password (LDAP for example).
But they still don't work because you did not use them before you logged
in.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
On some systems with a lot of users this creates a lot of extra DB
writes.
Being able to increase this interval helps there.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
When your password changes out of bounds your Nextcloud tokens will
become invalid. There is no real way around that. However we should make
sure that if you successfully log in again your passwords are all
updates
* Added event listener to the PostLoggedInEvent so that we can act on it
- Only if it is not a token login
* Make sure that we actually reset the invalid state when we update a
token. Else it keeps being marked invalid and thus not used.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
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>
This avoids hitting the backend with multiple requests for the same
token. And will help avoid quick LDAP lockouts.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
Env-based SAML uses the "Apache auth" mechanism to log users in. In this
code path, we first delete all existin auth tokens from the database,
before a new one is inserted. This is problematic for concurrent
requests as they might reach the same code at the same time, hence both
trying to insert a new row wit the same token (the session ID). This
also bubbles up and disables user_saml.
As the token might still be OK (both request will insert the same data),
we can actually just check if the UIDs of the conflict row is the same
as the one we want to insert right now. In that case let's just use the
existing entry and carry on.
Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>
* Order the imports
* No leading slash on imports
* Empty line before namespace
* One line per import
* Empty after imports
* Emmpty line at bottom of file
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
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>
Sometimes (esp with token auth) we query the same token multiple times.
While this is properly indexed and fast it is still a bit of a waste.
Right now it is doing very stupid caching. Which gets invalidate on any
update.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
This allows a user to mark a token for remote wipe.
Clients that support this can then wipe the device properly.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>
* 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>
* When getting the token
* When rotating the token
* Also store the encrypted password as base64 to avoid weird binary
stuff
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
Some bad databases don't respect the default null apprently.
Now even if they cast it to 0 it should work just fine.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
However due to the nature of what we store in the token (encrypted
passwords etc). We can't just delete the tokens because that would make
the oauth refresh useless.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
On a remembered login session, we create a new session token
in the database with the values of the old one. As we actually
don't need the old session token anymore, we can delete it right
away.
Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>
On renew, a session token is duplicated. For some reason we did
not copy over the remember-me attribute value. Hence, the new token
was deleted too early in the background job and remember-me did
not work properly.
Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>
