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

[OCM][Test Suite] Canonical format for fields in API Specification #157

Open
MahdiBaghbani opened this issue Dec 9, 2024 · 1 comment
Open
Assignees
Labels
enhancement New feature or request

Comments

@MahdiBaghbani
Copy link
Member

MahdiBaghbani commented Dec 9, 2024

Based on the JSON payload of the POST request to the /shares endpoint from different EFSSes detailed in #156, we can see there isn't an agreement on how to format the sender and owner fields, and neither do the API Specifications say anything about that.

So we have three possible formats appearing in the fields:

  1. userId@https://domain <---- ownCloud, oCIS
  2. userId@https://domain/ <---- Nextcloud versions 28 and lower
  3. userId@domain <---- Nextcloud versions 29 and later

The third option is the correct format, which should be mentioned in the API specification.

Also, there is a difference in the shareWith field as well:

  1. userId@https://domain <---- Nextcloud
  2. userId@domain <---- ownCloud, oCIS

@michielbdejong @glpatcern @mickenordin Would like to know your opinions on this matter.

@MahdiBaghbani MahdiBaghbani self-assigned this Dec 9, 2024
@MahdiBaghbani MahdiBaghbani changed the title [OCM][Test Suite] Canonical format for sender and owner in API Specification [OCM][Test Suite] Canonical format for fields in API Specification Dec 9, 2024
@glpatcern
Copy link
Contributor

My opinion would be to enforce userId@domain, but it's true this is not explicitly mentioned - and to add more entropy to the issue, even Reva internally had been mixing up the two formats (see e.g. cs3org/reva#3974).

@MahdiBaghbani I think you could raise this issue in the OCM-API repo - or even propose a PR to amend the spec with a format to use. That could just be a recommendation more than a prescription I guess, unless we decide all together to enforce it.

@MahdiBaghbani MahdiBaghbani added the enhancement New feature or request label Jan 8, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants