Despite it's PHPDoc the function might return `null` which was not properly catched and thus in some situations the share was resolved to the sharing users root directory.
To test this perform the following steps:
* Share file in owncloud 7 (7.0.4.2)
* Delete the parent folder of the shared file
* The share stays is in the DB and the share via the sharelink is inaccessible. (which is good)
* Upgrade to owncloud 8 (8.0.2) (This step is crucial. The bug is not reproduceable without upgrading from 7 to 8. It seems like the old tokens are handled different than the newer ones)
* Optional Step: Logout, Reset Browser Session, etc.
* Access the share via the old share url: almost empty page, but there is a dowload button which adds a "/download" to the URL.
* Upon clicking, a download.zip is downloaded which contains EVERYTHING from the owncloud directory (of the user who shared the file)
* No exception is thrown and no error is logged.
This will add a check whether the share is a valid one and also adds unit tests to prevent further regressions in the future. Needs to be backported to ownCloud 8.
Adding a proper clean-up of the orphaned shares is out-of-scope and would probably require some kind of FK or so.
Fixes https://github.com/owncloud/core/issues/15097
In the past it seems the update permission was needed to be able to
rename shared mounts, but it doesn't seem to be the case any more.
Removing the "update" permission that used to be added automatically
fixes the read-only permission check when trying to overwrite a
read-only file over WebDAV.
This is required because the PDF Viewer itself is embedded using an iframe from the same domain. The default policy is blocking this.
Going on further, we have to come up with a solution in the future how to handle previews by applications, one example might be that they call their own endpoint and not the generic share page to allow applications to have full control over how to display previews.
Anyways, to test this behaviour use a decent newer browser (such as Chrome 41) and share a PDF file, obviously the PDF viewer needs to be enabled as well. Without this patch publicly shared PDF files should not get previewed and an error is thrown. (if it isn't then your browser is probably not obeying our Content-Security-Policy and you might consider switching to another one ;))
Beside some small improvements and bug fixes this will probably the final state for OC8.
To test this you need to set up two ownCloud instances. Let's say:
URL: myPC/firstOwnCloud user: user1
URL: myPC/secondOwnCloud user: user2
Now user1 can share a file with user2 by entering the username and the URL to the second ownCloud to the share-drop-down, in this case "user2@myPC/secondOwnCloud".
The next time user2 login he will get a notification that he received a server-to-server share with the option to accept/decline it. If he accept it the share will be mounted. In both cases a event will be send back to user1 and add a notification to the activity stream that the share was accepted/declined.
If user1 decides to unshare the file again from user2 the share will automatically be removed from the second ownCloud server and user2 will see a notification in his activity stream that user1@myPC/firstOwnCloud has unshared the file/folder from him.
Whenever a file is shared with others or with link, a delete button used
to be visible that triggered a direct deletion.
This button has been removed to avoid accidental deletion from people
who might believe it was an unshare button. Unsharing is still possible
inside the share dropdown.
The "dir" key is used within the public sharing template to indicate in which directory the user currently is when sharing a directory with subdirectories. This is needed by the JS scripts.
However, when not accessing a directory then "dir" was set to the relative path of the file (from the user's home directory), meaning that for every public shared file the sharee can see the path.
(For example if you share the file "foo.txt" from "finances/topsecret/" the sharee would still see the path "finances/topsecret/" from the shared HTML template)
This is not the excpected behaviour and can be considered a privacy problem, this patch addresses this by setting "dir" to an empty key.
Bjoern Schiessle
Thomas Müller
Morris Jobke
Robin Appelman
Jenkins for ownCloud
Lukas Reschke
Robin Appelman
Joas Schilling
Roeland Jago Douma
Vincent Petry
Joas Schilling
Georg Ehrke
Vincent Cloutier