Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

deleting a folder should delete share links to it as well #801

Closed
butonic opened this issue Nov 4, 2020 · 3 comments
Closed

deleting a folder should delete share links to it as well #801

butonic opened this issue Nov 4, 2020 · 3 comments

Comments

@butonic
Copy link
Member

butonic commented Nov 4, 2020

With #627 we allow the core tests to fail on this scenario:

Scenario Outline: Uploading file to a public upload-only share using old public API that was deleted does not work # /srv/app/testrunner/tests/acceptance/features/apiSharePublicLink2/uploadToPublicLinkShare.feature:38 | 1149s
-- | --
6688 | Given using <dav-path> DAV path                                                                                  # FeatureContext::usingOldOrNewDavPath() | 1149s
6689 | And user "Alice" has created a public link share with settings                                                   # FeatureContext::userHasCreatedAPublicLinkShareWithSettings() | 1149s
6690 | \| path        \| FOLDER \| | 1149s
6691 | \| permissions \| create \| | 1149s
6692 | When user "Alice" deletes file "/FOLDER" using the WebDAV API                                                    # FeatureContext::userDeletesFile() | 1149s
6693 | Then uploading a file should not work using the old public WebDAV API                                            # PublicWebDavContext::publiclyUploadingShouldNotWork() | 1149s
6694 | And the HTTP status code should be "404"                                                                         # FeatureContext::thenTheHTTPStatusCodeShouldBe() | 1149s
6695 |   | 1149s
6696 | Examples: | 1149s
6697 | \| dav-path \| | 1149s
6698 | \| old      \| | 1149s
6699 | HTTP status code 401 is not the expected value 404 | 1149s
6700 | Failed asserting that 401 matches expected '404'. | 1149s
6701 | \| new      \| | 1150s
6702 | HTTP status code 401 is not the expected value 404 | 1150s
6703 | Failed asserting that 401 matches expected '404'.

The core reason is that while the folder is deleted, the share manager still remembers the share. but when trying to resolve the file it returns a permission denied instead of a not exists error

... maybe relevant:

it seems the ocs public file handler does not check the grpc response status code, only the err in

https://github.com/cs3org/reva/blob/4a28e84e33e437a2be9caaf58fa8f0f824c570cf/internal/http/services/owncloud/ocdav/publicfile.go#L98-L108

and

https://github.com/cs3org/reva/blob/4a28e84e33e437a2be9caaf58fa8f0f824c570cf/internal/http/services/owncloud/ocdav/publicfile.go#L157-L167

hm the lines I linked might actually be more relevant for https://github.com/owncloud/ocis-reva/issues/290

@butonic
Copy link
Member Author

butonic commented Nov 4, 2020

related cs3org/reva#1297

@kulmann
Copy link
Member

kulmann commented Nov 17, 2020

Will be fixed by #859

@refs
Copy link
Member

refs commented Jan 12, 2021

fixed on #859, until proven otherwise 🔨

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants