The phpdoc for the sharing functions was very restrictive. As a
consequence passing node object (for example from the OCS Share API
where we don't really care if it is a file or folder), would actually
be invalid.
With this loser restriction the interfaces become more generic.
The setup uses `\OCP\IRequest::getInsecureServerHost` which in some cases can also include a port. This makes the trusted domain check fail thus.
I've decided to add this here that way because adjusting the setup would require parsing the host properly. This is not something that can be done very good in PHP. Check the following example for why `parse_url` is not our friend: https://3v4l.org/k501Z
The SabreDAV release in 9.0 requires XMLReader, while this is usually compiled in by default some distributions like Gentoo don't.
Without this ownCloud gives a fatal 500 error instead of telling people to enable XMLReader.
Fixes https://github.com/owncloud/core/issues/23003
Fixes#22601
Before we did a full test on all chunks to verify if a chunked upload
was completed. This is unneeded since if we are missing one chunk we can
already fail.
Also we look from back to front since it is much more likely that we
find a missing chunk thus can error out early.
In the case of shared files, we have to call free_space() on the file
name. This has the side-effect that when uploading to a local storage
without quota set, it will call disk_free_space with the file name,
which fails.
This fix uses the parent folder in case the given path is a file.
* fixes#22819
The old way fired a DELETE statement on each destruction of the
DBLockingProvider. Which could cause a lot of queries. It's enough
to run this every 5 minutes in a background job, which in the end
could result in file locks that exists 5 minutes longer - in the
worst case and for not properly released locks.
This makes the DB based locking a lot more performant and could
result in a similar performance to the Redis based locking provider.
When calling `\OC\Files\View::copy` we should also keep the version to ensure that the file will always have the correct version attached and can be successfully decrypted.
To test this the following steps are necessary (from https://github.com/owncloud/core/issues/22781#issuecomment-191328982):
1. setup a new ownCloud 9.0 beta2
2. enable encryption
2. upload a docx (5.7MB large)
3. upload the same file again and overwrite the existing file
4. I can download the original file and the first version
5. I restore the first version
6. restored version can no longer be downloaded with the error described above
The manual cache operation in `\OCA\Files_Versions\Storage` is unfortunately necessary since `\OCA\Files_Versions\Storage::copyFileContents` is not using `\OCP\Files\Storage::moveFromStorage` in the case when an object storage is used. Due to the workaround added in 54cea05271 the stream is directly copied and thus bypassing the FS.
We should not scan any custom data directory in the integrity checker as well. Otherwise this would lead to a massive increased update time that may likely exceed the timeout.
To test this:
1. Install ownCloud 8.2.2, set as data dir another folder than `data` such as `data-asdf`. Make sure that folder lives in the web root as well.
2. Update that instance to 9.0.0 beta2 => Errors are shown in the code integrity check
3. Apply this patch and trigger the rescan in the admin settings => No errors are shown anymore (can also do a new update with that patch applied)
Fixes https://github.com/owncloud/core/issues/22698
Adds autodiscovery support to server-to-server sharing as specified in the specification. If no discovery data is found it is using the fallback ownCloud endpoints for legacy support.
Sharing of the users root folder should not be allowed as it is very
weird UX. Also many of our clients have no proper way of displaying
this.
Added unit test
Also added intergration tests to make sure we won't allow it in the
future.
This check will skip the background scan for the root storage
because there is nothing in the root storage that isn't already
in another (mostly user-) storage.
Fixes#22501
Some move operations when cross-storage will be replaced by copy and
delete. Before attempting this, first check whether the source storage
has delete permissions.
This also prevents renaming system-wide external storages.
Incomming federated shares are a special kind. We mount them as normal
webdav shares but we do supply owner info with the federated cloud id of
the share owner.
Since we do not yet have the new resharing behaviour on federated shares
we need to set the correct owner. Which will allow sharing and proper
mounting for other users.
fixes#22500
Fixes#22467
This can go wrong when an app (take the ldap app) DIs something that
needs the rootFolder. This break if we use cookie auth since then we
know the user at that point and thus try to setup the fs for that user.
However if there are then incomming shares from an ldap user they will
fails since the user manager can't find them yet.
Now getRootFolder does not setup the fs for any user.
When overwriting shared files as recipient, the part file is written on
the uploader's storage before overwriting the target file.
If the uploader has no quota left, they should still be able to
overwrite that file with Webdav. To make this work, they need to be able
to write the part file to their own storage first.
Roeland Jago Douma
Lukas Reschke
Thomas Müller
Joas Schilling
Vincent Petry
C. Montero Luque
Morris Jobke
Robin Appelman
Bjoern Schiessle
Scrutinizer Auto-Fixer
Victor Dubiniuk