Skip to content

Fix REPORT response from webdav #4485

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

Merged
merged 3 commits into from
Sep 2, 2022
Merged

Conversation

kobergj
Copy link
Collaborator

@kobergj kobergj commented Aug 31, 2022

There were multiple issue with REPORT search response from webdav. Also we want it to be consistent with PROPFIND endpoint.

  • the remote.php prefix was missing from the href (added even though not neccessary)
  • the ids were formated wrong, they should look different for shares and spaces.
  • the name of the resource was missing
  • the shareid was missing (for shares)
  • the prop shareroot (containing the name of the share root) was missing
  • the permissions prop was empty

owncloud/web#7557

@ownclouders
Copy link
Contributor

ownclouders commented Aug 31, 2022

💥 Acceptance test Core-API-Tests-ocis-storage-9 failed. Further test are cancelled...

@kobergj
Copy link
Collaborator Author

kobergj commented Aug 31, 2022

@ScharfViktor could you help me with the failing tests? We updated the REPORT endpoint to be consistent with the PROPFIND webdav endpoint:

  • we added the spaceid to the href (previously it was only storageid!opaqueid, now storageid$spaceid!opaqueid
  • we added a remote.php prefix to the url
  • we removed netencoding from the href (to be consistent with PROPFIND response)

It seems any of these three changes break the tests.
Do the test expect the href in a certain way? If so can we change that?
The last two bulletpoints are rather optional but the first one is a must have for proper functionality

@ScharfViktor
Copy link
Contributor

@ScharfViktor could you help me with the failing tests? We updated the REPORT endpoint to be consistent with the PROPFIND webdav endpoint:

  • we added the spaceid to the href (previously it was only storageid!opaqueid, now storageid$spaceid!opaqueid
  • we added a remote.php prefix to the url
  • we removed netencoding from the href (to be consistent with PROPFIND response)

It seems any of these three changes break the tests. Do the test expect the href in a certain way? If so can we change that? The last two bulletpoints are rather optional but the first one is a must have for proper functionality

Yes sure. let me switch to your branch and debug it local

@ScharfViktor
Copy link
Contributor

test failed because:

  1. https://github.com/owncloud/core/blob/master/tests/acceptance/features/bootstrap/WebDav.php#L5319
    here we get spaceId. spaceId looks like: 1284d238-aa92-42ce-bdc4-0b0000009157$5ae7fa50-cdf1-43d6-82a5-8f58c65c25f4
    Screenshot 2022-08-31 at 16 57 30
    but search result give us: /remote.php/dav/spaces/1284d238-aa92-42ce-bdc4-0b0000009157$5ae7fa50-cdf1-43d6-82a5-8f58c65c25f4!5ae7fa50-cdf1-43d6-82a5-8f58c65c25f4/upload😀 😁/upload😀 😁.txt

  2. here https://github.com/owncloud/core/blob/master/tests/acceptance/features/bootstrap/WebDav.php#L5326
    we create $topWebDavPath witch we search in REPORT request. it's ease -> just replace to "/remote.php/dav/spaces/"

@ScharfViktor
Copy link
Contributor

  • the ids were formated wrong, missing the spaceID

PROPFIND request give us: /remote.php/dav/spaces/1284d238-aa92-42ce-bdc4-0b0000009157$5ae7fa50-cdf1-43d6-82a5-8f58c65c25f4/upload%20folder/

should be results(REPORT and PROPFIND requests) be same?

@kobergj
Copy link
Collaborator Author

kobergj commented Sep 1, 2022

@ScharfViktor yes, the goal was to have them consistent. However there is one thing I don't understand. As you said spaceID looks like 1284d238-aa92-42ce-bdc4-0b0000009157$5ae7fa50-cdf1-43d6-82a5-8f58c65c25f4 why does search expect it to look like 1284d238-aa92-42ce-bdc4-0b0000009157!5ae7fa50-cdf1-43d6-82a5-8f58c65c25f4 ($ vs !). That is wrong in my opinion.

Second question, whats the usual way to fix such problems? Should I put them on expected failures, then fix the test and then remove them again? Or is there another procedure I should follow?

@ScharfViktor
Copy link
Contributor

why does search expect it to look like 1284d238-aa92-42ce-bdc4-0b0000009157!5ae7fa50-cdf1-43d6-82a5-8f58c65c25f4 ($ vs !). That is wrong in my opinion.

No, not exactly. search result returns us 1284d238-aa92-42ce-bdc4-0b0000009157$5ae7fa50-cdf1-43d6-82a5-8f58c65c25f4!5ae7fa50-cdf1-43d6-82a5-8f58c65c25f4 (3 uuid: storageId . "$" . spaceId . "!" spaceId again?? or opaqueid)

@ScharfViktor
Copy link
Contributor

Second question, whats the usual way to fix such problems? Should I put them on expected failures, then fix the test and then remove them again? Or is there another procedure I should follow?

Move please failed tests to expected failures. after merging your PR, I create 2 PRs (fix test in core and deleting tests from expected failures in ocis).

@ScharfViktor
Copy link
Contributor

should be results(REPORT and PROPFIND requests) be same?

What about this one? It's just that if I change search tests to new implementation-> propfind tests will be failed

@kobergj
Copy link
Collaborator Author

kobergj commented Sep 1, 2022

No, not exactly. search result returns us 1284d238-aa92-42ce-bdc4-0b0000009157$5ae7fa50-cdf1-43d6-82a5-8f58c65c25f4!5ae7fa50-cdf1-43d6-82a5-8f58c65c25f4 (3 uuid: storageId . "$" . spaceId . "!" spaceId again?? or opaqueid)

Yes exactly. That was a bug on my side. When comparing to PROPFIND it should be storageID$SpaceID/PATH I'll change it that way.

Move please failed tests to expected failures. after merging your PR, I create 2 PRs (fix test in core and deleting tests from expected failures in ocis).

Thanks! will do so.

What about this one? It's just that if I change search tests to new implementation-> propfind tests will be failed

The fields that are in both PROPFIND and REPORT should be consistent. However PROPFIND might contain more fields than REPORT does. That means no changes should be done to PROPFIND test, we want REPORT to behave like PROPFIND not the other way around

@kobergj kobergj force-pushed the FixSearchReport branch 3 times, most recently from 129d6b9 to 856c160 Compare September 2, 2022 08:21
Copy link
Contributor

@kulmann kulmann left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Commented on some typos, but otherwise looks good from what I can tell.

@sonarqubecloud
Copy link

sonarqubecloud bot commented Sep 2, 2022

Kudos, SonarCloud Quality Gate passed!    Quality Gate passed

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities
Security Hotspot A 0 Security Hotspots
Code Smell A 0 Code Smells

31.0% 31.0% Coverage
0.0% 0.0% Duplication

response := propfind.ResponseXML{
Href: net.EncodePath(path.Join("/dav/spaces/", match.Entity.Ref.ResourceId.StorageId+"!"+match.Entity.Ref.ResourceId.OpaqueId, match.Entity.Ref.Path)),
Href: net.EncodePath(path.Join("/remote.php/dav/spaces/", ref)),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why do we have to prefix with the legacy remote.php?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To be consistent with ocdav PROPFIND endpoint

@micbar
Copy link
Contributor

micbar commented Sep 18, 2023

@kobergj changelog and pull request id is not matching.

Can we fix that on master?

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

Successfully merging this pull request may close these issues.

6 participants