Open with app provider from public share

[wkloucek]

Is your feature request related to a problem? Please describe.

On a public link like https://ocis.owncloud.test/#/files/public/list/mDEidWobQFviKmE there is only the public link authentication. But that one can not be used to open files with the app provider since /app/open needs an REVA token internally (which comes from the oCIS proxy for normally authenticated users)

Describe the solution you'd like

expose the x-access-token which is scoped to the shared resource ( it is already used internally https://github.com/cs3org/reva/blob/a1a5d61a9ac015966e14bd3d2c20309bc22f5ae9/internal/http/services/owncloud/ocdav/dav.go#L216) to oC Web and so that it can then passed to the /app/open request. (Concern: are REVA tokens allowed to leave REVA?)

Describe alternatives you've considered

make the /app/open endpoint aware of public links but that would be more work!?

Additional context

• Needed for Open files via public link in associated App (Collabora, OnlyOffice, Word etc.) web#5776
• first week of sprint needs some more concepting (technical solution to be found)
• second week of sprint touchpoint with webteam is needed

[wkloucek]

@butonic @C0rby Do you think that solution is possible to unblock owncloud/web#5776?

[exalate-issue-sync]

Jörn Friedrich Dreyer commented: While we can expose the x-access-token for now we should rething how requests are authenticated.

When the x-access-token leaves the instance it should be replaced with a hash, similar to how openid connect recomments to use opaque auth tokens instead of jwt based ones.

In our casethe proxy looks up the userinfo, mints and caches an x-access-toksen for openid connect bearer tokens.

Not only our proxy needs to cache outgoing x-access-tokens and replace them with a hash: the gateway needs to do the same thing. A token returned in an HTTP PROPFIND might reach the gateway in a GRPC request. See the diagram attached above.

CERN is already working on this in cs3org/reva#1935

If the gateway returns hashes instead of x-access-tokens it forces all http services to lookup and cache the x-access-token. We could do that in the proxy though.

In the future, if the token grows too large we will have to replace it with a hash in the future anyway. Then all services will have to maintain their own token lookup cache ... well in a single binary we could use a shared in memory cache ... but ... yuck

This needs a proper ADR with pros and cons, explaining the tradeoffs.

[wkloucek]

Anonymous users are currently able to edit and save files on read only public link shares with the app provider / WOPI server. cs3org/reva#2214 fixes that.