[SPIKE] Deep Links 2.0

[jesmrec]

Research about handling deep links

Research 1.0: https://github.com/owncloud/enterprise/issues/4970#issuecomment-1042967713

What's expected on Deep Links:

user clicks on a link in the device (no matter where: mail, web...):

1. App is opened
2. Account is selected, if more than one
3. Browse through folder structure to reach the pointed item. In case it's not discovered, all the structure must be discovered on the road.

What should be researched:

• How brandable could the link be. Basic link is something like https://demo.owncloud.com/f/7. Prefix and URL to be brandable, so that we can open: mycompany://mycompany.thebest.com/index.php/f/13 with same effect. Scheme, host and preffix could have different values. (here there are some Android version regards, i guess). Desirable: use as default owncloud:// scheme.

• Check if this first iteration is still useful. In there, links to already discovered items are open. Branding options for host and preffix also there.

• Which information to be sent to backend team to make this posible. Automatic verifications could be involved (check this)

• Logic to develop, check feasibility and estimation (maybe the longest part)

  • Solve link to get the path to the item: https://github.com/owncloud/enterprise/issues/4970#issuecomment-1040540303
  • Browse/discover to open item (file or folder). Take in account the browsability.

• Does make sense to split up in different parts as in the 1st try?:

  • 1. Open discovered files and folders in single account
  • 2. Open non-discovered in single account
  • 3. Open anything in multiaccount

• If time allows, do a quick proof of concept of the easiest case

Any other idea ... always welcome.

[jesmrec]

@michaelstingl one questions about expected behaviour: working in both oC10 / oCIS? in that case, same link format in both?

In case of oCIS, we have to add another step: check which space/drive does contain the folder.

[michaelstingl]

oCIS focus. So yes, we'll have to deal with Spaces. But meta endpoint should provide this information:

• https://github.com/owncloud/enterprise/issues/5569#issuecomment-1578708489

[jesmrec]

oCIS focus. So yes, we'll have to deal with Spaces. But meta endpoint should provide this information:

this will translate the file id into a path to reach the file. But, does the link itself look like in oC10? (i hope so):

<scheme>://<url>/f/<some_id>

i did not find this kind of links in oCIS web, only the public links with the /s/ prefix.

[michaelstingl]

oCIS focus. So yes, we'll have to deal with Spaces. But meta endpoint should provide this information:

this will translate the file id into a path to reach the file. But, does the link itself look like in oC10? (i hope so):

<scheme>://<url>/f/<some_id>

i did not find this kind of links in oCIS web, only the public links with the /s/ prefix.

Public links with the /s/ prefix won't work, not in oC10, not with oCIS.

Valid oC10 links:

• Copied from browser bar: https://demo.owncloud.com/apps/files/?dir=/Hacker-Songs&fileid=12345
• Copied from browser bar: https://demo.owncloud.com/index.php/apps/files/?dir=/Hacker-Songs&fileid=12345
• Private link: https://demo.owncloud.com/f/12345
• Private link: https://demo.owncloud.com/index.php/f/12345

Valid oCIS links:

• Copied from browser bar: https://ocis.ocis-traefik.latest.owncloud.works/files/spaces/personal/einstein/Hacker-Songs?fileId=96fd1fa6-2d2a-4701-be6e-7d15a82ecd95%244c510ada-c86b-4815-8820-42cdf82c3d51%2101275b1d-f963-497e-9e76-7a46cf71d72b&items-per-page=100&view-mode=resource-table&tiles-size=1
• Id-only based URL as described in ADR-11: https://ocis.ocis-traefik.latest.owncloud.works/files?fileId=96fd1fa6-2d2a-4701-be6e-7d15a82ecd95%244c510ada-c86b-4815-8820-42cdf82c3d51%2101275b1d-f963-497e-9e76-7a46cf71d72b
• Private link (via desktop client): https://ocis.ocis-traefik.latest.owncloud.works/f/96fd1fa6-2d2a-4701-be6e-7d15a82ecd95$4c510ada-c86b-4815-8820-42cdf82c3d51%2101275b1d-f963-497e-9e76-7a46cf71d72b
• And of course links from oCIS activity mail notifications: https://ocis.ocis-traefik.latest.owncloud.works/f/96fd1fa6-2d2a-4701-be6e-7d15a82ecd95$4c510ada-c86b-4815-8820-42cdf82c3d51%2101275b1d-f963-497e-9e76-7a46cf71d72b

[michaelstingl]

oC10 link / fileid resolve

% curl -sI -u "test:test" "https://demo.owncloud.com/f/9" | grep "location"
location: /apps/files/?dir=/Photos
webdav-location: /remote.php/dav/files/test/Photos

• Add Webdav-Location header in private link redirect core#30383

oCIS link / fileid resolve

/remote.php/dav/meta/ could be used to get more information.

% curl -s 'https://ocis.ocis-traefik.latest.owncloud.works/remote.php/dav/meta/427a5e74-6921-4768-8d53-cd5e8b30f5b0%24534bb038-6f9d-4093-946f-133be61fa4e7!a130bbe3-5681-4193-9ab0-2a714934722a' \
-X 'PROPFIND' \
-H 'Authorization: Bearer REDACTED' \
-H 'Depth: 0' \
--data-binary $'<?xml version="1.0"?>\n<d:propfind  xmlns:d="DAV:" xmlns:oc="http://owncloud.org/ns">\n  <d:prop>\n    <oc:meta-path-for-user />\n  </d:prop>\n</d:propfind>' | xmllint --format -

<?xml version="1.0"?>
<d:multistatus xmlns:s="http://sabredav.org/ns" xmlns:d="DAV:" xmlns:oc="http://owncloud.org/ns">
  <d:response>
    <d:href>/remote.php/dav/meta/427a5e74-6921-4768-8d53-cd5e8b30f5b0$534bb038-6f9d-4093-946f-133be61fa4e7%21a130bbe3-5681-4193-9ab0-2a714934722a/</d:href>
    <d:propstat>
      <d:prop>
        <oc:meta-path-for-user>/Hacker-Songs</oc:meta-path-for-user>
        <oc:id>427a5e74-6921-4768-8d53-cd5e8b30f5b0$534bb038-6f9d-4093-946f-133be61fa4e7!a130bbe3-5681-4193-9ab0-2a714934722a</oc:id>
        <oc:fileid>427a5e74-6921-4768-8d53-cd5e8b30f5b0$534bb038-6f9d-4093-946f-133be61fa4e7!a130bbe3-5681-4193-9ab0-2a714934722a</oc:fileid>
        <oc:spaceid>427a5e74-6921-4768-8d53-cd5e8b30f5b0</oc:spaceid>
      </d:prop>
      <d:status>HTTP/1.1 200 OK</d:status>
    </d:propstat>
  </d:response>
</d:multistatus>

• https://doc.owncloud.com/server/developer_manual/webdav_api/meta.html

[michaelstingl]

@jesmrec @JuancaG05 please provide feedback/ideas if anything else needed from the backend

[manuelplazaspalacio]

I was researching the last week about this issue:

• For the first point, How brandeable could be the link:
  You always can use a custom scheme "http" or whatever you want and a custom host for open the app with a deep link. Not with an App link, that needs a scheme "http" or "https".
  You can find the differences between direct link and App link here: https://developer.android.com/training/app-links
• Check if this Open deep links in app, items already discovered (1st round) #3598 is still useful:
  I check the code and is useful, but I have to change parts of the code, because the OC code it is used has changed.
• Which information to be sent to backend team to make this posible:
  We need the backend to team develops something so that when opening a link in the browser of an Android device, it exhibits this behavior: https://github.com/owncloud/enterprise/issues/4970#issuecomment-1054274031
  But we don't need to publish anything for automatic verification if we don't use App Links.

I continue researching about the next points.
A video opening the oc://android.owncloud.com link in an Android with api 33:
test.webm

[michaelstingl]

• We need the backend to team develops something so that when opening a link in the browser of an Android device, it exhibits this behavior:

Tracked in:

• [web] Open in web or app banner web#9139

[manuelplazaspalacio]

I continue checking the possibilities tu open an url with a custom scheme in Android. I create an app to open a page with a "oc" scheme inside a webview. If you use the WebView as is, when you click on the link, the WebView displays an error saying it doesn't recognize that scheme. Later, I added the code shown below to handle deep links and it opens the ownCloud app correctly. So, there is a possibility that if you try to open the deep link from a WebView within an app, it may not open. On the other hand, I have tested it on the 9 most commonly used Android browsers and it works fine there.

override fun shouldOverrideUrlLoading(
                    view: WebView,
                    request: WebResourceRequest
                ): Boolean {
                    val url = request.url.toString()
                    try {
                        val intent = Intent(ACTION_VIEW, Uri.parse(url)).apply {
                            // The URL should either launch directly in a non-browser app (if it's
                            // the default), or in the disambiguation dialog.
                            addCategory(CATEGORY_BROWSABLE)
                            flags = FLAG_ACTIVITY_NEW_TASK or FLAG_ACTIVITY_REQUIRE_NON_BROWSER
                        }
                        startActivity(it, intent, null)
                    } catch (e: ActivityNotFoundException) {
                        // Only browser apps are available, or a browser is the default.
                        // So you can open the URL directly in your app, for example in a
                        view.loadUrl(url)
                    }
                    return true
                }

[michaelstingl]

On the other hand, I have tested it on the 9 most commonly used Android browsers and it works fine there.

This sounds great 👍

[manuelplazaspalacio]

I have been running tests, and I believe that with this, I can now consider the spike completed. I have obtained the file path through the request to "/remote.php/dav/meta/" with the file's ID. I have updated the containing folders of the file, and then I navigate to the file and display its details.

In this video, it shows how it navigate to the file's details automatically using the deep link, then I view the image and manually navigate back to the initial folder:

deeplinkFile.mp4

In this other video, I demonstrate how to navigate automatically to a folder using the deep link and then manually navigate back to the initial folder:

test.deeplink.folder.mp4

[jesmrec]

Everything done here. Let's archive this.