url without app in it's query redirects docx and odt file to onlyoffice url

[S-Panta]

Describe the bug

Desktop client for both open office and collaborate file opens the file in only office. Thus, the redirection link isn't correctly fixed

Desktop Client

Url from test /external/open-with-web/?appName=Collabora&fileId={file-id} is redirected to external-onlyoffice/personal/alice/OpenDocument.odt?appName=Collabora&fileId={file-id"

Mobile Client

Url from test /external?app=Collabora&contextRouteName=files-spaces-personal&fileId={file-id} is redirected to /external-collabora/personal/alice/OpenDocument.odt?fileId=:{file-id}

Setup

Please describe how you started the server and provide a list of relevant environment variables or configuration files.
Web: ownCloud Web UI 9.1.0-alpha.1
oCIS" Infinite Scale 6.0.0+747795b4a Community

[JammingBen]

I guess owncloud/ocis#9495 is the underlying issue here?

[S-Panta]

The failure caused by #11103 was fixed by #11113.
But it looks like every file is redirected to the office Should we wait for ocis to fix the main issue or fix the redirection in the frontend for now as a temporal fix?

[AlexAndBear]

The failure caused by #11103 was fixed by #11113.
But it looks like every file is redirected to the office Should we wait for ocis to fix the main issue or fix the redirection in the frontend for now as a temporal fix?

Fix in frontend maybe? because we already have a fallback implementation there.
@kulmann fyi

[kulmann]

I made #11134 to mitigate this.

But I'm kind of confused by the URLs from the report. Here is the spec: https://owncloud.dev/services/app-registry/#open-a-file-with-owncloud-web

The desktop client looks to me like it's creating the URL for the correct endpoint, but the query params should be lower_snake_case (backend seems to handle camelCase well though): /external/open-with-web/?appName=Collabora&fileId={file-id}

• it uses /external/open-with-web as endpoint
• it appends appName as query parameter
• why is appName as query parameter in the response?! Needs to be app. I added appName as additional fallback query param to my PR linked above.

What you posted from the mobile client seems to skip the ocis endpoint entirely and directly goes to a handcrafted web ui URL: /external?app=Collabora&contextRouteName=files-spaces-personal&fileId={file-id}. Is that correct?! Then this needs urgent fixing in the mobile client (which one, Android or iOS? or both?).

[kulmann]

@S-Panta @jesmrec could you please have a look at and comment on my previous post? ^ thank you!

[S-Panta]

The URL /external?app=Collabora&contextRouteName=files-spaces-personal&fileId={file-id} was added to the test code for mobile client by @ScharfViktor .
Regarding the client, I think the mobile team should be consulted to know what URL is used there.

[ScharfViktor]

The URL /external?app=Collabora&contextRouteName=files-spaces-personal&fileId={file-id} was added to the test code for mobile client by @ScharfViktor . Regarding the client, I think the mobile team should be consulted to know what URL is used there.

I guess that mobile team uses url as described here: #9804

[jesmrec]

The point here is, what's done and what's expected.

Android always requested open-with-web with the file_id and the app_name (from /app/list endpoint) to get the URL. The response is like:

{
    "uri": "https://ocis.ocis.master.owncloud.works/external?app=Collabora&contextRouteName=files-spaces-personal&fileId=<file-id>"
}

that is in the format that you mentioned.

iOS app calls app/open with a response in a different format like:

{
    "app_url": "https://collabora.ocis.master.owncloud.works/browser...",
    "form_parameters": {
        "access_token": "<token>",
        "access_token_ttl": "<token_ttl>"
    },
    "method": "POST"
}

the backend retrieved URLs are thrown to the browser.

[kulmann]

The point here is, what's done and what's expected.

Android always requested open-with-web with the file_id and the app_name (from /app/list endpoint) to get the URL. The response is like:

{
    "uri": "https://ocis.ocis.master.owncloud.works/external?app=Collabora&contextRouteName=files-spaces-personal&fileId=<file-id>"
}

that is in the format that you mentioned.

iOS app calls app/open with a response in a different format like:

{
    "app_url": "https://collabora.ocis.master.owncloud.works/browser...",
    "form_parameters": {
        "access_token": "<token>",
        "access_token_ttl": "<token_ttl>"
    },
    "method": "POST"
}

the backend retrieved URLs are thrown to the browser.

Thank you @jesmrec - the Android behaviour is perfect. 👍

So the iOS app doesn't even use the web ui but shows its own iframe with what comes back from the app/open endpoint? Then we don't have an issue either.

[jesmrec]

So the iOS app doesn't even use the web ui but shows its own iframe with what comes back from the app/open endpoint? Then we don't have an issue either.

that's it, but let's confirm with @felix-schwarz. Is that right?

[felix-schwarz]

@jesmrec @kulmann Depending on setting, the iOS client uses either

• open-with-web (in the way described above, opening the returned uri) - or -
• open (creating a web view and, within, opens app_url with the form_parameters according to the method)

By default, open is used.

[kulmann]

I mitigated the issue by allowing the appName url query param in web as well. Both mobile clients use the open-with-web ocis endpoint.

Anything that needs to be done in the tests @ScharfViktor ? Or can we close?

[ScharfViktor]

I mitigated the issue by allowing the appName url query param in web as well. Both mobile clients use the open-with-web ocis endpoint.

Anything that needs to be done in the tests @ScharfViktor ? Or can we close?

We can close it down. I checked and returned the tests here and the tests are green. https://drone.owncloud.com/owncloud/web/45652/15/16