Adapt to historical way of constructing WebDAV URL

[michielbdejong]

We need to adapt the behaviour of Reva to cs3org/OCM-API#70

[gmgigi96]

In particular: we need to get the specification of how OC10 and NC currently build the URL AND use the sharedSecret, so to 1) implement it in Reva as a route and 2) document it in the OCM API specs in the description of the (deprecated) webdav sharing payload.

[glpatcern]

A bit more context for why we need this - as I got lost myself :) and I'll need some confirmations here:

Assumption: the ScienceMesh app in OC10/NC would create OCM shares, which would be entirely channeled through Reva, such that the traffic goes like:

Site_A [ OC10 <--> Reva_A ] <-----> [ Reva_B <--> NC ] Site_B

Or in other words, the SM app in OC10/NC shall ensure that traffic is proxied through Reva, and then we can always assume that remote traffic is Reva-to-Reva - which provides the extra flexibility to drive the evolution of the ScienceMesh.

Implementation: for OC10/NC, the existing logic to browse a "remote" share is used as that's their native way. Therefore, the three arrows above seem to work as follows, from right to left, assuming that Marie@Site_B is accessing a share served by Einstein@Site_A:

1. NC@Site_B makes a "remote" access to the share (using the "historical way" we discuss here) to Reva_B (i.e. to the local Reva).
2. Reva_B forwards the request to Reva_A using the new way specified in OCM v1.1, i.e. using the whole webDAV path.
3. Reva_A serves the request by accessing OC10@A via the WebDAV storage driver.

Crucially, NC@Site_B shall not make a remote access to OC10@Site_A, bypassing Reva. Is all that right?

My doubt here is that an OCM share created via Reva through the SM app is actually persisted as an external share exactly like any other OCM share created by OC10/NC, and as such it seems it is "natively" or "externally" accessible by OC10/NC. How is it actually different? And how do we persist the OCM v1.1 properties such as the whole WebDAV path (and in the future the webapp path) that Reva_B needs to request to Reva_A in step 2?

[michielbdejong]

No, an easier way to understand it is that only the OCM create call goes through the reva's. After that, all interaction (WebDAV but actually now that I think of it, als OCM notifications) are directly between the two EFSSs.

That part is working (almost).

This issue is about making sure CERN can also join ScienceMesh. For that, it needs to implement WebDAV (as well as, now that I think of it, OCM notifications) in exactly the way the existing OCM implementations (OC10 and NC) expect.

So the CERN ScienceMesh node should:

• implement the /ocm-provider endpoint, specifying the WebDAV $PATH as mentioned in Document current translation that happens for webdav OCM-API#70
• implement a WebDAV interface that works on https://$TOKEN:@$HOST$PATH as specified in Document current translation that happens for webdav OCM-API#70

[michielbdejong]

You can choose your value for $PATH but you need to:

• accept http basic auth with username $TOKEN and password ''
• use the same path for all shares (the http basic auth username determines what the WebDAV client will find at that path)

[glpatcern]

No, an easier way to understand it is that only the OCM create call goes through the reva's. After that, all interaction (WebDAV but actually now that I think of it, als OCM notifications) are directly between the two EFSSs.

Hmm, this contradicts the assumption that all traffic is reva-to-reva though. Hugo mentioned this was the understanding as well, quoting you:

The advantage of bypassing Nextcloud-native webdav is that all the webdav traffic on the Sciencemesh will be reva-to-reva
(no questions of protocol compatibility) and streamed (fast and efficient).

Surely it's easier to make all interactions go through the native OCM implementations, but then we completely loose control on the mesh. I'm more afraid of this than of the additional implementation required in Reva - yes we'd need to implement notifications as well (whereas Reva still returns not implemented on /ocm/notifications...) on top of adapting /ocm-provider to fulfill the webdav access logic.

[gmgigi96]

To add this in reva, the way WebDAV is accessed by OC10/nextcloud should be part of the OCM specifications, as reva currently is doing the (correct) assumption that @glpatcern already described.

[michielbdejong]

Sure, you can add it in the spec so you can justify implementing it in Reva. Both things can happen in parallel.

[glpatcern]

Yes, this is what I have in mind indeed, now that you have fully reverse engineered it.