"Open in Web" for native clients

[pmaier1]

Story As a client user I want to open a file in the Web Office directly from the context menu in my file browser so that I can easily start collaborating with others

Specifics

• Infinite Scale only
• Use App provider backend
• Timeline ~ mid August

@TheOneRing

[pmaier1]

Any update? cc @michaelstingl @dragotin

[TheOneRing]

I can start working on it next week.

[TheOneRing]

Doc: https://owncloud.dev/services/app-registry/apps/ Test url: https://ocis.ocis-wopi.latest.owncloud.works/app/list

[wkloucek]

Turns out that the current approach that fits well for ownCloud web doesn't fit the Desktop Client.

Main problem is that the Desktop client can only use mechanisms like xdg-open https:/..... on Linux and similar mechanisms on other systems to open a website in the system default browser. This always performs a GET request on the given URL.

WOPI standards defines that you should open the WOPI office application in an iframe. That requirement could maybe be dropped. But the standard also defines that the WOPI office application must be opened with a form POST and the access token must be transported in the form data.

Some WOPI office applications ignore that standard and optionally allow to be opened with a GET request and the access token as query parameter in the URL. Collabora is an example for that class. Other WOPI office applications like OnlyOffice and Microsoft Office Online don't allow this.

The current development state of this feature uses the GET approach and therefore only works with Collabora.

In order to support more office suites we have following options:

1. Desktop Client hosts a small website The Desktop Client hosts a small website with an iframe and some basic javascript that performs the same form POST as oC Web does. We would then need to allow localhost in the CORS policies of the Web office, which is not too nice.

2. Desktop Client opens oC Web (separate authentication) The Desktop Client just opens oC Web in the document edit view. If no session is active in the browser, the user needs to login first. This is the most secure approach since no access tokens need to be passed around, that end up in the browser history (query parameters from GET requests end there). This is not really convenient for the user. The URL to be opened would look like this: https://ocis.ocis-wopi.latest.owncloud.works/external?app=Collabora&fileId=1284d238-aa92-42ce-bdc4-0b0000009157%24b334d680-c516-4aa1-9d45-53e13bd82a56%21795bd5fe-2a7f-498d-ab3e-28c887f03c47

3. Desktop Client opens oC Web (caring about authentication) The Desktop Client opens oC Web and passes the WOPI access token to oC Web. Downside is that the access token would end in the browser history. The URL to be opend would look like this: https://ocis.ocis-wopi.latest.owncloud.works/external?app=Collabora&fileId=1284d238-aa92-42ce-bdc4-0b0000009157%24b334d680-c516-4aa1-9d45-53e13bd82a56%21795bd5fe-2a7f-498d-ab3e-28c887f03c47&access_token=lorem&access_token_ttl=1234

I would go for solution 2) because it does not need changes in oC Web and is the most secure solution.

@pmaier1 are you ok with solution 2? @kulmann is the url for solution 2 expected to be stable?

[pmaier1]

@pmaier1 are you ok with solution 2?

Well, not really happy having to reauthenticate, of course. I agree that 3 would probably also get criticized. If you don't see other solutions, let's go for 2 for now.

[TheOneRing]

Relevant discussion https://chat.owncloud.com/channel/ocis-internal?msg=gEsa7WyZRTFL8Q3YX

[wkloucek]

Relevant discussion https://chat.owncloud.com/channel/ocis-internal?msg=gEsa7WyZRTFL8Q3YX

I don't think that it is possible in a clean way to share the OIDC session from the Desktop client to the browser. It would basically mean that we need to transfer the offline token, which could lead to a ended session in the client (depending on the IDP settings, eg Keycloak's Refresh Token Max Reuse == 0)

If we're thinking about SSO that is not only used by ownCloud, but also by other applications (in the Web browser) there is quite a chance that the user is already authenticated. It also depends on the session timeouts set on the IDP how often a user needs to re-authenticate itself.

[pmaier1]

Alright, thanks for the background. I think solution 2 will work now, as said above.

[wkloucek]

Info from @kulmann is that this URL is currently not yet stable. We will need to discuss that tomorrow.

[michaelstingl]

2. Desktop Client opens oC Web (separate authentication) The Desktop Client just opens oC Web in the document edit view. If no session is active in the browser, the user needs to login first.

This is what I'd expect with the given possibilities. Handing-over authentication from native apps to the web needs a bigger concept. Happy to discuss with the backend experts at a later stage…

[wkloucek]

When https://github.com/cs3org/reva/pull/3143 and https://github.com/owncloud/ocis/pull/4376 are merged, following functionality is available: https://github.com/owncloud/ocis/blob/7ef7a60d710f2ac582a64417c03b0f0f4336261d/docs/services/app-registry/apps.md#open-a-file-with-the-owncloud-web

[wkloucek]

The /app/open-with-web endpoint is now available on oCIS master / latest deployments (see also https://owncloud.dev/services/app-registry/apps/#app-provider-capability)