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>
"Exception: substr() expects parameter 3 to be int, bool given" can occur on Line 378 $mimePart = substr($icon, 0, strpos($icon, '-'));
This happens, when '-' is not found and strpos returns false instead of an int.
When this occurs, e.g., Activity hangs.
Signed-off-by: lui87kw <lukas.ifflaender@uni-wuerzburg.de>
We don't use `shareapi_internal_enforce_expire_date` anywhere.
`shareapi_enforce_internal_expire_date` is the one we want.
Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>
The default expiration date for internal shares was set from the default
link expiration date instead of the internal one.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
In certain cases changeLock to EXCLUSIVE fails
and throws LockedException. This leaves the
file locked as SHARED in file_put_contents,
which prevents retrying (because on second
call file_put_contents takes another SHARED
lock on the same file, and changeLock doesn't
allow more than a single SHARED lock to promote
to EXCLUSIVE).
To avoid this case, we catch the LockedException
and unlock before re-throwing.
Signed-off-by: Ashod Nakashian <ashod.nakashian@collabora.co.uk>
The comparisson of NULL is a bit special.
So we need to handle this a tad beter else it might not replace NULL
values. or allow you to set NULL values on updates.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
This is within the failed lock acquiring branch. So the lock is free by another process and should not be removed because the cached file (that was created by the process having the lock) appeared on the filesystem.
Signed-off-by: Morris Jobke <hey@morrisjobke.de>
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 asking for sharees we compare not only UID and displayname but also
the email address. And if that matches we return the sharee as an exact
match. This logic had a flaw as in that it also matched the empty string
to users with no email address.
This is most noticeable when you disable sharee enumeration and open the
ownership transfer dialog. It suggested other users of the instance
before. This has stopped now.
Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>
Before when you have a user "smith" and a federated user "smith@example.com"
you could see the federation result with "smit" but not with "smith" anymore.
With most LDAP configurations and local backend setups this is disturbing and
causes issues.
The idea of not showing the email and federation on a matching user was with:
Local user registered with "smith@example.com" user id and having that same
email / cloud id in your contacts addressbook. So we now only hide those
"side results" when the search does contain an @
Signed-off-by: Joas Schilling <coding@schilljs.com>
Since we try to do range requests this will fail hard.
However since empty files are not that interesting to read anyways we
just read from an emptry memory stream.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
Since all the compiled routes are based on the server webroot,
we have to use this, independent from which app this belongs to.
Signed-off-by: Joas Schilling <coding@schilljs.com>
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>
Else we might run into the issue that for an external storage where the
size is not known yet we do not use zip64. Which then of course fails on
large zip files.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
If the object store errors we should not always delete the filecache
entry. As this might lead to people losing access to their files.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
instead of showing the generic 'Your storage is full' message, better explain that it's the group folder/external storage that is full
Signed-off-by: Robin Appelman <robin@icewind.nl>
* Systems that upgrade have this enabled by default
* New systems disable it
* We'll have to add some wargning in the setup checks if this is enabled
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
having the "cache rename" after the "storage move" caused the target
to get the fileid from the source file, without taking care that the object
is stored under the original file id.
By doing the "cache rename" first, we trigger the "update existing file"
logic while moving the file to the object store and the object gets stored for the
correct file id
Signed-off-by: Robin Appelman <robin@icewind.nl>
this allows an admin to configure the max trashbin size instead of always relying on the users quota.
The trashbin size can be configured using the `occ trash:size` command and can be set both globally and per-user
Signed-off-by: Robin Appelman <robin@icewind.nl>
Else people might have the feeling this is also doing 2FA. And since it
is only prefered it can be ignored and hacked around.
Once we have proper 2FA with webauthn in one go this probably needs to
be revisted.
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.
Signed-off-by: Lionel Elie Mamane <lionel@mamane.lu>
If we use the owners mount point this results in null. And then the rest
of the checks get called with null. Which doesn't work.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>