| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Signed-off-by: Robin Appelman <robin@icewind.nl>
|
|
|
|
| |
Signed-off-by: Robin Appelman <robin@icewind.nl>
|
|
|
|
| |
Signed-off-by: Joas Schilling <coding@schilljs.com>
|
|
|
|
| |
Signed-off-by: Joas Schilling <coding@schilljs.com>
|
|\
| |
| | |
fix: Do not build encrypted password if there is none
|
| |
| |
| |
| | |
Signed-off-by: Julius Knorr <jus@bitgrid.net>
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
| |
Signed-off-by: yemkareems <yemkareems@gmail.com>
|
|
|
|
| |
Signed-off-by: yemkareems <yemkareems@gmail.com>
|
|
|
|
| |
Signed-off-by: provokateurin <kate@provokateurin.de>
|
|
|
|
| |
Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>
|
|
|
|
| |
Signed-off-by: Daniel Kesselberg <mail@danielkesselberg.de>
|
|
|
|
| |
Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>
|
|
|
|
| |
Signed-off-by: Arthur Schiwon <blizzz@arthur-schiwon.de>
|
|
|
|
| |
Signed-off-by: Andy Scherzinger <info@andy-scherzinger.de>
|
|
|
|
| |
Signed-off-by: Andrew Summers <18727110+summersab@users.noreply.github.com>
|
|
|
|
| |
Signed-off-by: Benjamin Gaussorgues <benjamin.gaussorgues@nextcloud.com>
|
|
|
|
| |
Signed-off-by: Alexander Piskun <bigcat88@icloud.com>
|
|
|
|
|
| |
Signed-off-by: Joas Schilling <coding@schilljs.com>
Signed-off-by: Benjamin Gaussorgues <benjamin.gaussorgues@nextcloud.com>
|
|
|
|
| |
Signed-off-by: Lucas Azevedo <lhs_azevedo@hotmail.com>
|
|
|
|
| |
Signed-off-by: Côme Chilliet <come.chilliet@nextcloud.com>
|
|
|
|
| |
Signed-off-by: Joas Schilling <coding@schilljs.com>
|
|
|
|
| |
Signed-off-by: Joas Schilling <coding@schilljs.com>
|
|
|
|
| |
Signed-off-by: Côme Chilliet <come.chilliet@nextcloud.com>
|
|
|
|
| |
Signed-off-by: Artur Neumann <artur@jankaritech.com>
|
|
|
|
| |
Signed-off-by: Joas Schilling <coding@schilljs.com>
|
|
|
|
| |
Signed-off-by: Côme Chilliet <come.chilliet@nextcloud.com>
|
|
|
|
| |
Signed-off-by: Marcel Klehr <mklehr@gmx.net>
|
|
|
|
|
|
|
| |
* IDBConnection import missing
* Atomic doesn't need a mock
Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>
|
|
|
|
| |
Signed-off-by: Julius Härtl <jus@bitgrid.net>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|\
| |
| | |
Add fallback routines for empty secret cases
|
| |
| |
| |
| | |
Signed-off-by: Carl Schwan <carl@carlschwan.eu>
|
| |
| |
| |
| | |
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>
|
| |
| |
| |
| | |
Signed-off-by: Joas Schilling <coding@schilljs.com>
|
| |
| |
| |
| | |
Signed-off-by: Joas Schilling <coding@schilljs.com>
|
|/
|
|
| |
Signed-off-by: Joas Schilling <coding@schilljs.com>
|
|
|
|
| |
Signed-off-by: Joas Schilling <coding@schilljs.com>
|
|
|
|
| |
Signed-off-by: Joas Schilling <coding@schilljs.com>
|
|
|
|
| |
Signed-off-by: Joas Schilling <coding@schilljs.com>
|
|
|
|
| |
Signed-off-by: Côme Chilliet <come.chilliet@nextcloud.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
| |
Signed-off-by: Joas Schilling <coding@schilljs.com>
|
|
|
|
| |
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
|
|
|
|
|
|
|
|
|
| |
* Fix namespace
* Fix test
Was broken after https://github.com/nextcloud/server/pull/26529
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
|
|
|
|
|
|
|
| |
* Shiny new events
* Listener to still emit the old event
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
|