feat(CloudFederationApi): Start implementation of 1.1.0 of OCM spec

[mickenordin]

• Resolves: Implement OCM v1.1 #38886

Summary

This is a VIP implementation of OCM 1.1.0

https://cs3org.github.io/OCM-API/docs.html?branch=v1.1.0&repo=OCM-API&user=cs3org

Notes

• /shares

  • outgoing: https://github.com/nextcloud/server/blob/master/lib/private/Federation/CloudFederationProviderManager.php#L140
  • incoming: https://github.com/nextcloud/server/blob/master/apps/cloud_federation_api/lib/Controller/RequestHandlerController.php#L81

• /notifications

  • outgoing: https://github.com/nextcloud/server/blob/master/lib/private/Federation/CloudFederationNotification.php
  • incoming:

    server/apps/cloud_federation_api/lib/Controller/RequestHandlerController.php

    Line 209 in 46340d1

    public function receiveNotification($notificationType, $resourceType, $providerId, ?array $notification) {

TODO

• Send a correct response on /ocm-provider according to spec: https://cs3org.github.io/OCM-API/docs.html?branch=v1.1.0&repo=OCM-API&user=cs3org#/paths/~1ocm-provider/get
• Implement invitation work flow, so that we can send invites, that means storing a mapping token when we share that we can use to look up info about the share when we receive an /invite-accepted call
  • Send out invitations and store generated tokens for later retrival
  • Receive accepted invitations on /invite-accepted https://cs3org.github.io/OCM-API/docs.html?branch=v1.1.0&repo=OCM-API&user=cs3org#/paths/~1invite-accepted/post
• /notifications
  • Receive correctly formated notifications of all types
  • Send correctly formated notifications of supported types https://cs3org.github.io/OCM-API/docs.html?branch=v1.1.0&repo=OCM-API&user=cs3org#/paths/~1notifications/post
• /shares
  • Protocol field for /shares now have a different format from before and needs to be updated https://cs3org.github.io/OCM-API/docs.html?branch=v1.1.0&repo=OCM-API&user=cs3org#/paths/~1shares/post
  • We should send 1.1.0 shares if possible
• Access
  • make sure we handle access to shares correctly with bearer tokens and such: https://cs3org.github.io/OCM-API/#access
  • Deprecate access to shares using token in url

[mickenordin]

If someone wants to join the fun, I can add them to the SUNET repo on request.

Ping @ArtificialOwl and @provokateurin 😄

[provokateurin]

Nice to see someone starting to implement it. Given the PR cs3org/OCM-API#89 it seems like a v1.2 implementation will be necessary too in the near future. Do you think it makes sense to tackle them both at once or at least in series? Otherwise Nextcloud will continue to lack support for the latest version :/

[provokateurin]

The openapi.json is generated from our source code and should not be overwritten by the real specification (CI will fail). In this case though it's a nice tool to verify that the specs match.

[mickenordin]

The openapi.json is generated from our source code and should not be overwritten by the real specification (CI will fail). In this case though it's a nice tool to verify that the specs match.

Ooops. will revert that.

[mickenordin]

Nice to see someone starting to implement it. Given the PR cs3org/OCM-API#89 it seems like a v1.2 implementation will be necessary too in the near future. Do you think it makes sense to tackle them both at once or at least in series? Otherwise Nextcloud will continue to lack support for the latest version :/

I think it makes sense to do 1.1 first. It will be easier to do 1.2 in direct succession to that.

[mickenordin]

By diffing the 1.0.0 version of the spec and the 1.1.0 version, this is what we can find:

/ocm-provider endpoint is new (nextcloud has that)
/shares has sender as a new required property
/shares shareType now have a defined enum of types, user, group and federation
/shares has expiration as new optional property
/shares protocol now enumerates the supported choices webdav, webapp and datatx
/shares protocol also  has a new format:
(note: the keys 'singleProtocolLegacy, singleProtocolNew and multiProtocol' are not actual keys, but different examples)
"protocol": {

    "singleProtocolLegacy": 

{

    "name": "webdav",
    "options": 

    {
        "sharedSecret": "hfiuhworzwnur98d3wjiwhr",
        "permissions": "some permissions scheme"
    }

},
"singleProtocolNew": 
{

    "name": "webdav",
    "options": 

{

    "sharedSecret": "hfiuhworzwnur98d3wjiwhr"

},
"webdav": 
{

    "sharedSecret": "hfiuhworzwnur98d3wjiwhr",
    "permissions": 

        [
            "read"
        ],
        "uri": "https://open-cloud-mesh.org/remote.php/webdav/share-secret/path/to/resource.txt"
    }

},
"multipleProtocols": 
{

    "name": "multi",
    "options": null,
    "webdav": 

{

    "permissions": 

    [
        "read"
    ],
    "uri": "https://open-cloud-mesh.org/remote.php/webdav/share-secret/path/to/resource.txt"

},
"webapp": 
{

    "uriTemplate": "[https://open-cloud-mesh.org/s/share-hash/{relative-path-to-shared-resource}](https://open-cloud-mesh.org/s/share-hash/%7Brelative-path-to-shared-resource%7D)",
    "viewMode": "read"

},
"datatx": 

    {
        "srcUri": "https://open-cloud-mesh.org/remote.php/webdav/share-secret/path/to/resource.txt",
        "size": 100000
    }

}

vs the old:

"protocol": {

    "name": "webdav",
    "options": 

    {
        "sharedSecret": "hfiuhworzwnur98d3wjiwhr",
        "permissions": "{http://open-cloud-mesh.org/ns}share-permissions"
    }

}

/invite-accepted is added to support the invitation workflow

[mickenordin]

@provokateurin do you think we can ha a ocm room/chat at cloud.nextcloud.com's talk instance?

It would be good if we could chat about things, as there comes up questions when you start to look at the code :)

[provokateurin]

I think https://cloud.nextcloud.com/call/4606076295 already fits, then others can easily join the conversation as well.

[mickenordin]

I think https://cloud.nextcloud.com/call/4606076295 already fits, then others can easily join the conversation as well.

Also, we have a Matrix room for the OCM working group at: https://matrix.to/#/%23cs3org_OCM%3Agitter.im?via=gitter.im&via=matrix.org&via=matrix.datenschmutz.space&via=hu-berlin.de

[github-actions]

Hello there,
Thank you so much for taking the time and effort to create a pull request to our Nextcloud project.

We hope that the review process is going smooth and is helpful for you. We want to ensure your pull request is reviewed to your satisfaction. If you have a moment, our community management team would very much appreciate your feedback on your experience with this PR review process.

Your feedback is valuable to us as we continuously strive to improve our community developer experience. Please take a moment to complete our short survey by clicking on the following link: https://cloud.nextcloud.com/apps/forms/s/i9Ago4EQRZ7TWxjfmeEpPkf6

Thank you for contributing to Nextcloud and we hope to hear from you soon!

(If you believe you should not receive this message, you can add yourself to the blocklist.)

[mickenordin]

Seems to me notifications were allready compliant with 1.1, development version of the spec is more strict on notification types, but it is not released yet.

[michielbdejong]

Deprecate access to shares using token in url

Unlike Reva which used to put the shareSecret in the url path or query, I think what the WebDAV API currently does is accept the sharedSecret as the username in http basic auth. So in a sense it's in the url, but on the wire it will look like an Authorization: Basic ... header, right?

[mickenordin]

Deprecate access to shares using token in url

Unlike Reva which used to put the shareSecret in the url path or query, I think what the WebDAV API currently does is accept the sharedSecret as the username in http basic auth. So in a sense it's in the url, but on the wire it will look like an Authorization: Basic ... header, right?

Do you know @ArtificialOwl ? If that is the case, it should be ok for 1.1 and we switch to shortlived bearer token in 1.2 then.

[michielbdejong]

Should we merge #45979 into this so that @MahdiBaghbani and @shokri-navid can start working on the tests for the use of http signatures in OCM?

[mickenordin]

I think we should keep them separate, as signatures will be a feature of 1.2. Michiel de Jong ***@***.***> skrev: (20 september 2024 11:39:02 CEST)

…

Should we merge #45979 into this so that @MahdiBaghbani and @shokri-navid can start working on the tests for the use of http signatures in OCM? -- Reply to this email directly or view it on GitHub: #47199 (comment) You are receiving this because you authored the thread. Message ID: ***@***.***>