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.
Whenever a remote fed share's shareinfo call returns a 404, don't
directly assume the storage is not available by throwing
StorageNotAvailableException. We need to properly throw
NotFoundException to trigger the later logic that calls testRemote()
that verifies that the 404 is not from a broken server but really from
an obsolete share.
$view->getUidAndFilename($filename); returns the federated cloud id in case of
a federated share. But in this case we need the local user who "owns" the file
which is the current logged in user in case of a federated share
Added in isSharable() in incoming remote share.
Added in isSharable() in regular incoming share.
Added in FileInfo to make sure the proper attributes are returned to the
clients.
Fixes#20769
When I receive a share and move a share of myself into that share (which
is allowed currently) I effectively hand over ownership of the files I
move. So we need to update the share I move to have as a parent the
share I move it into. Else our mounting system gets confused.
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.
* setup LDAP users
* share from an LDAP user
* delete that LDAP user
* log in as share recipient
* before: unhandled NoUserException
* after: NoUserEception is logged and share is not shown anymore
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
* list incoming remote shares at 'remote_shares'
* get per share info at 'remote_shares/<ID>'
* delete remote share with a DELETE to 'remote_shares/<ID>'
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
When a public link password has been input, its auth is stored in the
session.
This fix makes it possible to recognize the session when using public
webdav from the files UI.
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