In case of a write-only share we should not allow to specify a subfolder as this is unexpected behaviour.
Signed-off-by: Lukas Reschke <lukas@statuscode.ch>
A federated share can report unlimited quota as -3, so the
ajax/upload.php code needs to be adjusted to block uploads when the free
space is unlimited.
When receiving a shared file, the quota for that file counts in the
owner's storage, not the current user's storage.
To make it possible to overwrite the file even when the current user
doesn't have enough space, the quota check is deferred for such files.
The public page now uses the public.php/webdav endpoint.
Also enabled more file operations like rename, move, delete and create
folder from the public page, which are now all possible thanks to the
public.php/webdav endpoint.
* this code adds a cookie when a special get parameter is set
* the content of this get parameter is used as value for the cookie
* the cookie expires after 20 seconds
* the JS code checks every 500 milliseconds for the cookie
-> if the cookie is set the request returned and the download is started
This enforces proper types on POST and GET arguments where I considered it sensible. I didn't update some as I don't know what kind of values they would support 🙈
Fixes https://github.com/owncloud/core/issues/14196 for core
Some code paths called the `normalizePath` functionality with types other than a string which resulted in unexpected behaviour.
Thus the function is now manually casting the type to a string and I corrected the usage in list.php as well.
`\OCA\Files\Helper::buildFileStorageStatistics` might throw an exception from `OC_Helper::getStorageInfo`, previously this lead to a uncatched exception being thrown when invoking this methods.
This was user triggable by for example calling `/index.php/apps/files/ajax/delete.php` with a not existing dir (for example `dir=asdf/../&allfiles=true`)
Furthermore a not logged-in user was able to access this page before which resulted in a Fatal PHP error since the filesystem could not get setup properly.
Otherwise when the file without any specified mimetype was accessed the error log was flooded with entries such as "Undefined index: mime", there can be multiple issues found about this in the forum and our bugtracker.
To test this access `/index.php/apps/files/ajax/mimeicon.php` with and without `$_GET['mime']`.
Fixes itself.
Moved populateTags to be done on the main file list.
This prevents the public file list to go through the same code and cause
an error when there is no user.