send (MOVE,COPY) requests to another user's webDav endpoints as normal user gives 400 instead of 404

[SwikritiT]

Describe the bug

A clear and concise description of what the bug is.

Steps to reproduce

Steps to reproduce the behavior:

1. As user alice create file textfile0.txt
2. As user Brian send MOVE request to Alices endpoint /remote.php/dav/files/Alice/textfile0.txt

Expected behavior

As in oc10 it should return with 403

MOVE /core/remote.php/dav/files/Alice/textfile0.txt HTTP/1.1
Host: 172.17.0.1
User-Agent: GuzzleHttp/7
Destination: /path/to/destination
Authorization: basic QnJpYW46MTIzNA==
OCS-APIREQUEST: true
Content-Length: 13

doesnotmatter
HTTP/1.1 403 Forbidden
Date: Thu, 26 May 2022 10:07:22 GMT
Server: Apache/2.4.41 (Ubuntu)
X-Content-Type-Options: nosniff
X-XSS-Protection: 0
X-Robots-Tag: none
X-Frame-Options: SAMEORIGIN
X-Download-Options: noopen
X-Permitted-Cross-Domain-Policies: none
Set-Cookie: oc5soe2gvutv=2rmte6l4ik88ptsp32670gbn84; path=/core; HttpOnly; SameSite=Strict
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate
Pragma: no-cache
Set-Cookie: oc_sessionPassphrase=gHxym9szoLrNrSsPX%2Bp%2BIMQ7dq5sfyU4ApcVWsykP8mjCOjE4i%2F9DqW9ubaw4cNHGGYk3orY0IhgHKZHj4JKRRqbQUSkMop5PUS3rTYDxRHfnvyX0Hg5Hp%2FEn1CII25C; expires=Thu, 26-May-2022 10:27:22 GMT; Max-Age=1200; path=/core; HttpOnly; SameSite=Strict
Content-Security-Policy: default-src 'none';
Set-Cookie: oc5soe2gvutv=evmhenrj369hc3cll51133brdu; path=/core; HttpOnly; SameSite=Strict
Set-Cookie: cookie_test=test; expires=Thu, 26-May-2022 11:07:22 GMT; Max-Age=3600
Content-Length: 272
Content-Type: application/xml; charset=utf-8

<?xml version="1.0" encoding="utf-8"?>
<d:error xmlns:d="DAV:" xmlns:s="http://sabredav.org/ns">
  <s:exception>Sabre\DAV\Exception\Forbidden</s:exception>
  <s:message>Requested uri (/path/to/destination) is out of base uri (/core/remote.php/dav/)</s:message>
</d:error>

Actual behavior

Returns 400

MOVE /remote.php/dav/files/Alice/textfile0.txt HTTP/1.1
Host: localhost:9200
User-Agent: GuzzleHttp/7
Destination: /path/to/destination
Authorization: basic QnJpYW46MTIzNA==
OCS-APIREQUEST: true
Content-Length: 13

doesnotmatterHTTP/1.1 400 Bad Request
Access-Control-Allow-Origin: *
Content-Length: 0
Content-Security-Policy: default-src 'none';
Date: Thu, 26 May 2022 10:32:55 GMT
X-Content-Type-Options: nosniff
X-Download-Options: noopen
X-Frame-Options: SAMEORIGIN
X-Permitted-Cross-Domain-Policies: none
X-Robots-Tag: none
X-Xss-Protection: 1; mode=block

Setup

Please describe how you started the server and provide a list of relevant environment variables.

OCIS_VERSION=latest
BRANCH=master
STORAGE_FRONTEND_UPLOAD_DISABLE_TUS=false

Additional context

Add any other context about the problem here.

[butonic]

Actually, ocis and oc10 MUST return 415 (Unsupported Media Type) as per RFC4918 Section 8.4 - Required Bodies in Requests:

Some of these new methods do not define bodies. Servers MUST examine
all requests for a body, even when a body was not expected. In cases
where a request body is present but would be ignored by a server, the
server MUST reject the request with 415 (Unsupported Media Type).
This informs the client (which may have been attempting to use an
extension) that the body could not be processed as the client
intended.

A MOVE request has no body, but the request presented above sends doesnotmatter. Can we just send an empty body?

[phil-davis]

Issue owncloud/core#40126 raised. I will get someone to sort that out ASAP.

[phil-davis]

Issue owncloud/core#40126 raised. I will get someone to sort that out ASAP.

[C0rby]

So I just tested this and requests to another users resources now always return 404.
I also opened a PR for the request body check: cs3org/reva#2974

[SwikritiT]

Reopening this as there are still some tests linked to this issue in expected to fail

ocis/tests/acceptance/expected-failures-API-on-OCIS-storage.md

Lines 901 to 907 in 0676828

	#### [send MOVE requests to another user's webDav endpoints as normal user gives 400 instead of 403](https://github.com/owncloud/ocis/issues/3882)
	_ocdav: api compatibility, return correct status code_
	- [apiAuthWebDav/webDavMOVEAuth.feature:57](https://github.com/owncloud/core/blob/master/tests/acceptance/features/apiAuthWebDav/webDavMOVEAuth.feature#L57) Scenario: send MOVE requests to another user's webDav endpoints as normal user
	- [apiAuthWebDav/webDavMOVEAuth.feature:66](https://github.com/owncloud/core/blob/master/tests/acceptance/features/apiAuthWebDav/webDavMOVEAuth.feature#L66) Scenario: send MOVE requests to another user's webDav endpoints as normal user using the spaces WebDAV API

We probably need to split the tests according to the behavior of oc10 and ocis because it oc10 the request returns 403

Scenario: send MOVE requests to another user's webDav endpoints as normal user
    When user "Brian" requests these endpoints with "MOVE" about user "Alice"
      | 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 "403"

TODO QA Team:

• make the tests to match the current ocis behaviour and remove the tests linked to this issue from expected to failure
  • [tests-only] fix MOVE with another user dav path scenarios #8460

[SwikritiT]

So I just tested this and requests to another users resources now always return 404. I also opened a PR for the request body check: cs3org/reva#2974

@C0rby Hi are you sure this is fixed the test still report that the status code is 400 locally and also fails on CI. gives me the same response through curl
https://drone.owncloud.com/owncloud/ocis/13478/41/7

Scenario: send MOVE requests to another user's webDav endpoints as normal user # /drone/src/oc10/testrunner/tests/acceptance/features/apiAuthWebDav/webDavMOVEAuth.feature:57
    When user "Brian" requests these endpoints with "MOVE" about user "Alice"    # OCSContext::userSendsRequestToTheseEndpointsWithOutBody()
      | 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 "403"      # FeatureContext::theHTTPStatusCodeOfResponsesOnAllEndpointsShouldBe()
      Responses did not return expected http status code
      Failed asserting that 400 is identical to 403.

[kiranparajuli589]

blocked util #3882 (comment)

[amrita-shrestha]

blocked until this issue resolved : #5009

[saw-jan]

#3882 (comment)

So I just tested this and requests to another users resources now always return 404.
I also opened a PR for the request body check: cs3org/reva#2974

Trying to MOVE with another user's endpoint return 404

curl -XMOVE "https://localhost:9200/remote.php/dav/files/demo/myfile.txt" \
-H"Destination: https://localhost:9200/remote.php/dav/files/admin/moved.txt" \
-uadmin:admin -vk

< HTTP/1.1 404 Not Found
< Content-Length: 0

So, closing this here

[saw-jan]

Tests fixed in #8460