mirror/opencloud
1
0
Fork 0
mirror of https://github.com/opencloud-eu/opencloud.git synced 2026-04-27 22:41:10 -05:00
Code Issues Packages Projects Releases Wiki Activity

update ADR with manual get through webUI

Browse Source
This commit is contained in:
A.Unger
2021-07-06 18:23:26 +02:00
committed by Jörn Friedrich Dreyer
parent adc21d8f0b
commit 1a8e00b19e
1 changed files with 33 additions and 16 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/ocis/adr/0009-routes.md
+33 -16
View File
@@ -1,15 +1,16 @@
## Problem Statement
When we speak about routes we have to make a difference between browser routes and internal API calls. Browser routes are interpreted by the web client (owncloud/web) to construct API calls<sup>1</sup>. With this in mind, this is the mapping on ownCloud Web:
When we speak about routes we have to make a difference between browser routes and internal API calls. Browser routes are interpreted by the web client (owncloud/web) to construct API calls. With this in mind, this is the mapping on ownCloud Web with OC10 and OCIS backend:
| | Browser URL | Internal Resolution |
|------|---------------------------------------------------------------|-------------------------------------------------|
| OCIS | `https://host/#/files/list/all/TEST` | `https://host/remote.php/webdav/TEST` |
| OC10 | `https://host/index.php/apps/files/?dir=/TEST&fileid=5472225` | `https://host/remote.php/dav/files/aunger/TEST` |
| | Browser URL | Internal Resolution |
|------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------|
| OC10 | `https://host/index.php/apps/files/?dir=/TEST&fileid=5472225` | `https://host/remote.php/dav/files/aunger/TEST` |
| OCIS | `https://host/#/files/list/all/TEST` | `https://host/remote.php/webdav/TEST` |
| OCIS (after this ADR is implemented) | `https://host/#/space/relative/path?id=b78c2044-5b51-446f-82f6-907a664d089c:194b4a97-597c-4461-ab56-afd4f5a21607` | `https://host/remote.php/webdav/space/relative/path?id=b78c2044-5b51-446f-82f6-907a664d089c:194b4a97-597c-4461-ab56-afd4f5a21607` |
Note that with an OC10 backend ownCloud's Web format remains unchanged: `https://host/index.html#/files/list/all/TEST` -- still resolves to --> `https://host/remote.php/webdav/TEST`. So here we have to make a distinction and limit the scope of this ADR to "how will a web client deal with browser urls?"<sup>2</sup>
Note that with an OC10 backend ownCloud's Web format remains unchanged: `https://host/index.html#/files/list/all/TEST` -- still resolves to --> `https://host/remote.php/webdav/TEST`. So here we have to make a distinction and limit the scope of this ADR to "how will a web client deal with the browser url?"
Worth mentioning that on an OC10 backend it seems that `fileid` query parameter takes precedence over the `dir`. In fact if `dir` is invalid but `fileid` isn't, the resolution will succeed, as opposed to if the `fileid` is wrong and `dir` correct, resolution will fail altogether.
Worth mentioning that on an OC10 backend it seems that `fileid` query parameter takes precedence over the `dir`. In fact if `dir` is invalid but `fileid` isn't, the resolution will succeed, as opposed to if the `fileid` is wrong (doesn't exist) and `dir` correct, resolution will fail altogether.
## Use private links as routes
@@ -29,16 +30,15 @@ Let's have a look at the following scenario:
_fig. 1_
We can observe that the private link can still remain the unchanged, this should provide functionality with existing bookmarks. In order for bookmarked private links to work, the migration from OC10 to OCIS should have taken effect, and the recommended SQL storage provider should be in use, this will allow the OCIS backend to resolve the ID's pre-migration.
We observe that the private link can still remain the unchanged, this should provide functionality with existing bookmarks. In order for bookmarked private links to work, the migration from OC10 to OCIS should have taken effect, and the recommended SQL storage provider should be in use, this will allow the OCIS backend to resolve the IDs pre-migration.
Let us break down every step of figure 1.
Let us break down every step of _fig. 1_.
1. `GET https://cloud.ocis.com/index.php/f/5472225`
- all the web client has to "remember" is the id of the resource
2. `[303] Location=/marketing/path/to/file?id=storageid:resourceid`
- all the web client has to "remember" is the ID of the resource
2. Server's response: `Status=303 Location=/marketing/path/to/file?id=storageid:resourceid`
- the server will resolve the file by ID and provide with a URL for the webUI to render of the format: `/space/relative/path?id=b78c2044-5b51-446f-82f6-907a664d089c:194b4a97-597c-4461-ab56-afd4f5a21607`
3. `PROPFIND https://host/remote.php/webdav/TEST`
- To adjust to the new format, this WebDAV URL `MUST` change. If we don't have a namespace we can easily encounter naming collisions with different storage spaces<sup>1</sup>. A proposed WebDAV url format is recommended at this step of the following format: `https://host/remote.php/webdav/space/path/to/file?id=storageid:resourceid` which is provided by the server's original resolution.
3. `PROPFIND https://host/remote.php/webdav/space/path/to/file?id=storageid:resourceid`
When it comes to display the path, in order to avoid leaking parent information because the resource is shared, the rules in the following diagram `MUST` be followed:
@@ -48,17 +48,34 @@ When it comes to display the path, in order to avoid leaking parent information
Receiving a GET request to the following resource `GET https://cloud.ocis.com/index.php/f/5472225` will trigger a few hops that `MUST` be cached in order to prevent slow response times. The nature of these requests can be cached because the resources ID are not subject to changes.
The server `MUST` have a way to resolve the `ID=5472225`. The easiest approach that comes to mind is using the SQL storage driver, that provides compatibility when it comes to migrating files from an OC10 to an OCIS backend. The queried ID already exists in the DB, and the storage driver will just pull all the info it needs to construct the URL to set in the `Location` header of the response.
The server `MUST` have a way to resolve the `ID=5472225` (step 2 of the previous paragraph). The easiest approach that comes to mind is using the SQL storage driver, that provides compatibility when it comes to migrating files from an OC10 to an OCIS backend. The queried ID already exists in the DB, and the storage driver will just pull all the info it needs to construct the URL to set in the `Location` header of the response.
Let us breakdown each section (except the obvious):
Let us breakdown each section:
`/f/` = private link prefix. This is a convention.
`/space/` = space name. In which storage space does the target file / folder exist.
`/relative/path/` = path of the target file / folder relative to the storage space.
`?id=[...]` = combination of `storage_id` + `:` + `resource_id`
`?id=[...]` = combination of `storage_id` + `:` + `resource_id` that are gathered by the driver.
With all the above data we can start building the Location response header.
Support for the following paths `MUST` occur in order to provide power uses path-base navigation using the webUI: ``
## Manipulating the path in the URL
Suppose a power user knows where their resources are and wants to navigate only by modifying the request in the webUI. The user goes to the browser and changes:
`https://host/space/relative/path?id=b78c2044-5b51-446f-82f6-907a664d089c:194b4a97-597c-4461-ab56-afd4f5a21607`
to
`https://host/space/relative/path/deeper/file/inside?id=b78c2044-5b51-446f-82f6-907a664d089c:194b4a97-597c-4461-ab56-afd4f5a21607`
Notice that the ID has not changed. Path based resolution should take precedence over ID resolution<sup>2</sup>. Now we have a `GET` request that the webUI has to adapt to the server's format:
## Footnotes
- <sup>1</sup> is this a real concern? Need read proof.
- <sup>2</sup> really? this needs to be discussed, but it makes sense in this context, as the IDs are not human readable.