Now that we support multiple managers we communicate shares to the
outside as 'providerId:shareId'. This makes sures that id's are unique
when references from the OCS API.
However, since we do not want to break the OCS API v1 we need to
somewhat hack around this.
When we switch to OCS API v2 (which we should when we support more
custom providers). We will change the id to always be the fullShareId.
When a file/folder is shared with a group and one of the group members
moves this file/folder an extra entry is created in the share table.
When the permission of the group share is updated we used to only
sometimes update the shares for individual users.
* Added intergration tests
Instead of prepending the token as username in the URL, use the
Authorization header instead. This is because IE9 considers this a
cross-domain call and refuses to do it in the first place.
This is for apps that use getDownloadUrl() to access the Webdav endpoint
for example for streaming.
Also happens when clicking on the download action of a file.
Note that the regular visible download URL is still the same.
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.
Currently the `getPath` methods returned `NULL` in case when a file with the specified ID does not exist. This however mandates that developers are checking for the `NULL` case and if they do not the door for bugs with all kind of impact is widely opened.
This is especially harmful if used in context with Views where the final result is limited based on the result of `getPath`, if `getPath` returns `NULL` PHP type juggles this to an empty string resulting in all possible kind of bugs.
While one could argue that this is a misusage of the API the fact is that it is very often misused and an exception will trigger an immediate stop of execution as well as log this behaviour and show a pretty error page.
I also adjusted some usages where I believe that we need to catch these errors, in most cases this is though simply an error that should hard-fail.
use default config for swift primary storage test config
allow testsuite to complete
fix timeout, script cleanup, enable debug for now
use btrfs loopback device, requires privileged container and absolute path
throw exception when storage has problems
debug by echo ...
sleep more, more debug
Added new annotations for the externalsharescontroller class
* @NoOutgoingFederatedSharingRequired
* @NoIncomingFederatedSharingRequired
By default both are required for all functions in the
externalSharesController.
A proper exception is thrown and then a 405 is returned instead of the
default error page. Since it is only an API endpoint this makes more
sense.
Unit tests added and updated
Since for external shares there is no need for link shares to be enabled
we should check which controller is actually being called.
This makes sure that in all cases we verify that the files_sharing app
is enabled. But only for the share controller (public shares) we check
if the API is enabled and if links are enabled.
TODO: add checks for federated sharing as well
The sharing backend may throw another exception for example when the activity app encounters a problem. Previously this just triggered a 404 error page and the exception got not logged at all. With this change such exceptions get not intercepted and regularly handled as exceptions so that we have meaningful log data. Also the user will be shown a window informing him that an error happened.
Helps to debug cases such as https://github.com/owncloud/core/issues/19465
This makes it possible for the recipient to still trigger the sidebar
and share tab to see information about the share.
In the case where the file is not shared and no permissions exists, no
action icon will be displayed.
If the sharing API setting is disabled that sharing check middle ware
should block the request. Thus making link shares unavailable.
Fixes#18970
* Unit test added
* Unit tests updated
Since this extends the API we now properly parse the date. We only
accept valid ISO 8601 Dates (YYYY-MM-DD).
Currently this only works for link shares (it is just ignored for other
shares). Since we do not have user/group/federated expiring shares yet.
* Tests added