So far, the functions to find user statuses listed didn't respect user
enumeration settings (`shareapi_allow_share_dialog_user_enumeration`
and `shareapi_restrict_user_enumeration_to_group` core app settings).
Fix this privacy issue by returning an empty list in case
`shareapi_allow_share_dialog_user_enumeration` is unset or
`shareapi_restrict_user_enumeration_to_group` is set.
In the long run, we might want to return users from common groups if
`shareapi_restrict_user_enumeration_to_group` is set. It's complicated
to implement this in a way that scales, though. See the discussion at
https://github.com/nextcloud/server/pull/27879#pullrequestreview-753655308
for details.
Also, don't register the user_status dashboard widget at all if
`shareapi_allow_share_dialog_user_enumeration` is unset or
`shareapi_restrict_user_enumeration_to_group` is set.
Fixes: #27122
Signed-off-by: Jonas Meurer <jonas@freesources.org>
The "federated" and "published" scopes are independent one from each
other, so the capability that encompassed both needs to be split.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
If the Federation app is disabled it is not possible to synchronize the
users from a different server.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When the lookup server is disabled the address books can still be
exchanged between trusted servers. Therefore the user should be able to
set the "Federated" scope in that case.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
As a developer I have no clue what "Invalid route name" means. If the
exception gives me a hint I might find it easier to figure out why my
route triggers this error.
Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>
For local users it's possible to select their calendar via the principal url and first update their own attendance status.
External users have no calendar event hence the recipient is the organizer.
Signed-off-by: Daniel Kesselberg <mail@danielkesselberg.de>
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>
