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

Fixed paths used in the discovery endpoint #76

Merged
merged 2 commits into from
Jul 6, 2023

Conversation

glpatcern
Copy link
Member

@glpatcern glpatcern commented Jun 13, 2023

This follows a reverse engineering session to expose a share from CERNBox to ownCloud 10 and Nextcloud 26. Closes #70.

  • OC10 access works
    - [ ] NC26 access works

Edit: Nextcloud has been proven to follow the OCM standard when sending a share to a remote system, but to fully disregard it when accessing a remote system. Details in the comment below and in pondersource/nc-sciencemesh#373. Therefore, the amended text just reflects how ownCloud 10 accesses remote OCM shares, that essentially boils down to exposing paths and not full URLs in the /ocm-provider discovery endpoint.

This is to reflect how ownCloud and Nextcloud are actually using
the /ocm-provider endpoint to access a share, following further
reverse engineering.
@glpatcern glpatcern marked this pull request as draft June 13, 2023 14:59
@glpatcern glpatcern marked this pull request as ready for review June 15, 2023 17:11
@glpatcern
Copy link
Member Author

To keep a summary record of the investigations concerning Nextcloud, this is how it accesses a remote OCM share.

To be noted that part of this logic appears to come from the Open Collaboration Services standard (see #70), part is Nextcloud's own logic.

  1. Check the remote /ocm-provider endpoint and ensure that apiVersion = 1.0-proposal1. Otherwise, bail out.
  2. Send an OCM notification that the share has been accepted, and ensure it return 201 CREATED. Otherwise, bail out.
  3. Check the remote /ocs-provider endpoint. Possibly take services.FEDERATED_SHARING.endpoints.webdav as <path> for later accessing (not confirmed).
  4. Check that /status.php returns HTTP 200. This endpoint is exposed by ownCloud and Nextcloud, and the check is to ensure that the remote end is either ownCloud or Nextcloud. If not, bail out.

Nextcloud may eventually call POST /index.php/apps/files_sharing/shareinfo, passing as t query parameter the sharedSecret of the share. This is expected to give info about the remote share within a pure Nextcloud federation, and it's a fallback mechanism when one of the previous checks failed. But it is not called when accessing a ownCloud 10 share.

@michielbdejong
Copy link
Contributor

michielbdejong commented Jul 6, 2023

I can confirm point 1, my ocm-stub serves the exact string 1.0-proposal1 as its OCM version and you're correct to note that using semver here would be better.

But from memory I can't confirm points 2, 3 and 4, would be nice to create explicit tests for this in the ocm test suite!

Copy link
Contributor

@michielbdejong michielbdejong left a comment

Choose a reason for hiding this comment

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

LGTM

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.

Document current translation that happens for webdav
2 participants