update reva & add share prefix to ocs shared with me paths

[C0rby]

Fixes: owncloud/product#204

[C0rby]

Ok the tests fail because the file_target has the /Shares/ prefix now.
Also I need to look into the currently skipped tests which test the behavior of the storage with the /Shares/ prefix e.g. owncloud/product#203

[phil-davis]

I was expecting to find that the related core API test scenario started to pass. But https://drone.owncloud.com/owncloud/ocis/1962/21/6 and https://drone.owncloud.com/owncloud/ocis/1962/22/6

  Scenario: send PROPFIND requests to another user's webDav endpoints as normal user                          # /srv/app/testrunner/tests/acceptance/features/apiAuthWebDav/webDavPROPFINDAuth.feature:37
    When user "Brian" requests these endpoints with "PROPFIND" to get property "d:getetag" about user "Alice" # OCSContext::userSendsRequestToTheseEndpointsWithProperty()
      | endpoint                                           |
      | /remote.php/dav/files/%username%/textfile0.txt     |
      | /remote.php/dav/files/%username%/PARENT            |
      | /remote.php/dav/files/%username%/PARENT/parent.txt |
    Then the HTTP status code of responses on all endpoints should be "404"                                   # FeatureContext::theHTTPStatusCodeOfResponsesOnAllEndpointsShouldBe()
      Responses did not return expected http status code
      Failed asserting that 403 is identical to 404.

oC10 core responds with 404. But the OCIS code here is responding with 403 (the same issue on both storages)
What to do?

[phil-davis]

Suggested change

	The path of files shared with me using the ocs api we pointing to an incorrect location.
	The path of files shared with me using the ocs api was pointing to an incorrect location.

[refs]

I recommend doing make clean build locally so that ocis/go.sum updates reva as well

[C0rby]

I was expecting to find that the related core API test scenario started to pass. But https://drone.owncloud.com/owncloud/ocis/1962/21/6 and https://drone.owncloud.com/owncloud/ocis/1962/22/6

  Scenario: send PROPFIND requests to another user's webDav endpoints as normal user                          # /srv/app/testrunner/tests/acceptance/features/apiAuthWebDav/webDavPROPFINDAuth.feature:37
    When user "Brian" requests these endpoints with "PROPFIND" to get property "d:getetag" about user "Alice" # OCSContext::userSendsRequestToTheseEndpointsWithProperty()
      | endpoint                                           |
      | /remote.php/dav/files/%username%/textfile0.txt     |
      | /remote.php/dav/files/%username%/PARENT            |
      | /remote.php/dav/files/%username%/PARENT/parent.txt |
    Then the HTTP status code of responses on all endpoints should be "404"                                   # FeatureContext::theHTTPStatusCodeOfResponsesOnAllEndpointsShouldBe()
      Responses did not return expected http status code
      Failed asserting that 403 is identical to 404.

oC10 core responds with 404. But the OCIS code here is responding with 403 (the same issue on both storages)
What to do?

I feel like we "fixed" that exact things multiple times and it changed everytime....
@refs @butonic, what response code do we want here?

[refs]

@C0rby @butonic merged a PR on reva: cs3org/reva#1354 is all I'm aware of. I've been in my own auth bubble

[C0rby]

Ok now I got it...
The response code was 207 before, now somebody changed it to 403 (which makes more sense) but in OC10 the same request would return a 404. Should we leave the 403 or should I open another PR in reva to change it to 404?

[C0rby]

Ok, @refs and I decided to delete the test and leave the response code as it is for now.
If we need to change it we can do it in another PR

[refs]

LGTM, we got ourselves in a catch 22 with that phoenix PR

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
No Duplication information

[phil-davis]

we got ourselves in a catch 22 with that phoenix PR

There is some work happening to have an expected-failures file for the phoenix UI tests. I will chase that up tomorrow. That would have let us add some expected-failures with comments about what was going on, then remove them in a later PR, and always have CI showing green.