Replacement for TokenInfo Endpoint
Description
Apart from just re-implementing the tokeninfo logic for sharing-ng, we could try to find a cleaner way to get the same functionality. After some some discussion we came up with this, which should not need a tokeninfo endpoint at all and could purely work with webdav. It is still somewhat rough and we would have to prove that it does actually work:
The client should basically always sent a PROPFIND to /dav/public-files/{sharetoken}
- authenticated clients accessing an internal link are redirected to the "real" resource (`/dav/spaces/{target-resource-id}
- authenticated clients accessing a pubic link (password protected or not) for a resource they already have access to are also redirected to the "real" resource. (and always need to supply the password)
- unauthenticated clients accessing an internal link get a 401 returned with
WWW-Authenticateset toBearer(so that the client knows that it need to get a token via the IDP login page. - unauthenticated clients accessing a password protected link get a 401 returned with
WWW-Authenticateset toBasicto indicate the requirement for needing the link's password.
This would however require some changes our ocdav service (it does not handled the above request on the publicstorageids yet) and AFAICS also in the way we handle authentication for ocdav. So it requires some more research.
User Stories
-
As a client, i want to understand the context of my link (internal, public, password-protected) to give my users the best User Experience
Value
UX
Acceptance Criteria
- [ ] The requirements from above are fulfillable with WebDAV
Definition of ready
- [ ] Everybody needs to understand the value written in the user story
- [ ] Acceptance criteria have to be defined
- [ ] All dependencies of the user story need to be identified
- [ ] Feature should be seen from an end user perspective
- [ ] Story has to be estimated
- [ ] Story points need to be less than 20
Definition of done
- Functional requirements
- [ ] Functionality described in the user story works
- [ ] Acceptance criteria are fulfilled
- Quality
- [ ] Code review happened
- [ ] CI is green (that includes new and existing automated tests)
- [ ] Critical code received unit tests by the developer
- Non-functional requirements
- [ ] No sonar cloud issues
- Configuration changes
- [ ] The next branch of the ocis charts is compatible
I've adjusted the initial description a bit. In the discussion in #8617 we agreed on the initial WebDAV endpoint for public links being /dav/public-files/{sharetoken} to avoid more usage of hardcoded server uuid's. (See https://github.com/owncloud/ocis/issues/8617#issuecomment-2034610431)
@micbar @rhafer @kobergj Please have a look at the POC.
It still needs to change the response format for the internal link PROPFIND request.
<d:multistatus xmlns:s="http://sabredav.org/ns" xmlns:d="DAV:" xmlns:oc="http://owncloud.org/ns">
<d:response>
<d:href>/remote.php/dav/public-files/spaces/storage-users-1$some-admin-user-id-0000-000000000000%21b0985455-4a74-4a90-98b0-e8e153e45f51/</d:href>
<d:propstat>
<d:prop>
<oc:permissions>S</oc:permissions>
<oc:favorite>0</oc:favorite>
<oc:fileid>storage-users-1$some-admin-user-id-0000-000000000000!b0985455-4a74-4a90-98b0-e8e153e45f51</oc:fileid>
<oc:file-parent>storage-users-1$some-admin-user-id-0000-000000000000!some-admin-user-id-0000-000000000000</oc:file-parent>
<oc:name>f2</oc:name>
<oc:share-types>
<oc:share-type>0</oc:share-type>
</oc:share-types>
<oc:privatelink>https://localhost:9200/f/storage-users-1$some-admin-user-id-0000-000000000000%21b0985455-4a74-4a90-98b0-e8e153e45f51</oc:privatelink>
<oc:size>0</oc:size>
<d:getlastmodified>Mon, 22 Apr 2024 16:26:09 GMT</d:getlastmodified>
<d:getetag>"0b708c66b247127357ecefdd6aadecf0"</d:getetag>
<d:resourcetype>
<d:collection/>
</d:resourcetype>
<oc:tags></oc:tags>
</d:prop>
<d:status>HTTP/1.1 200 OK</d:status>
</d:propstat>
<d:propstat>
<d:prop>
<oc:owner-id></oc:owner-id>
<oc:owner-display-name></oc:owner-display-name>
<oc:shareroot></oc:shareroot>
<d:getcontentlength></d:getcontentlength>
<d:getcontenttype></d:getcontenttype>
<oc:downloadURL></oc:downloadURL>
</d:prop>
<d:status>HTTP/1.1 404 Not Found</d:status>
</d:propstat>
</d:response>
<d:response>
<d:href>/remote.php/dav/public-files/spaces/storage-users-1$some-admin-user-id-0000-000000000000%21b0985455-4a74-4a90-98b0-e8e153e45f51/f2fl1.txt/</d:href>
<d:propstat>
<d:prop>
<oc:permissions></oc:permissions>
<oc:favorite>0</oc:favorite>
<oc:fileid>storage-users-1$some-admin-user-id-0000-000000000000!6e14bcfc-a997-410a-889c-fbb7ab52dd97</oc:fileid>
<oc:file-parent>storage-users-1$some-admin-user-id-0000-000000000000!b0985455-4a74-4a90-98b0-e8e153e45f51</oc:file-parent>
<oc:name>f2fl1.txt</oc:name>
<oc:privatelink>https://localhost:9200/f/storage-users-1$some-admin-user-id-0000-000000000000%216e14bcfc-a997-410a-889c-fbb7ab52dd97</oc:privatelink>
<oc:size>0</oc:size>
<d:getlastmodified>Mon, 22 Apr 2024 16:26:09 GMT</d:getlastmodified>
<d:getetag>"3c9d1b04a808215002b85c56c81d5356"</d:getetag>
<d:resourcetype>
<d:collection/>
</d:resourcetype>
<oc:tags></oc:tags>
</d:prop>
<d:status>HTTP/1.1 200 OK</d:status>
</d:propstat>
<d:propstat>
<d:prop>
<oc:owner-id></oc:owner-id>
<oc:owner-display-name></oc:owner-display-name>
<oc:shareroot></oc:shareroot>
<oc:share-types></oc:share-types>
<d:getcontentlength></d:getcontentlength>
<d:getcontenttype></d:getcontenttype>
<oc:downloadURL></oc:downloadURL>
</d:prop>
<d:status>HTTP/1.1 404 Not Found</d:status>
</d:propstat>
</d:response>
</d:multistatus>
Against the public link response:
<d:multistatus xmlns:s="http://sabredav.org/ns" xmlns:d="DAV:" xmlns:oc="http://owncloud.org/ns">
<d:response>
<d:href>/remote.php/dav/public-files/csgVsREiAOeCxAa/</d:href>
<d:propstat>
<d:prop>
<oc:permissions>Z</oc:permissions>
<oc:fileid>storage-users-1$some-admin-user-id-0000-000000000000!ad0788f4-abbc-4adb-9de3-c3729e26ea3a</oc:fileid>
<oc:file-parent>storage-users-1$some-admin-user-id-0000-000000000000!some-admin-user-id-0000-000000000000</oc:file-parent>
<oc:name>csgVsREiAOeCxAa</oc:name>
<oc:owner-id>admin</oc:owner-id>
<oc:owner-display-name>Admin</oc:owner-display-name>
<oc:privatelink>https://localhost:9200/f/storage-users-1$some-admin-user-id-0000-000000000000%21ad0788f4-abbc-4adb-9de3-c3729e26ea3a</oc:privatelink>
<d:getlastmodified>Wed, 17 Apr 2024 10:32:32 GMT</d:getlastmodified>
<d:getetag>"9139088991bbebbd3e762394a48a0b3c"</d:getetag>
<d:resourcetype>
<d:collection/>
</d:resourcetype>
<oc:tags></oc:tags>
</d:prop>
<d:status>HTTP/1.1 200 OK</d:status>
</d:propstat>
<d:propstat>
<d:prop>
<oc:favorite></oc:favorite>
<oc:shareroot></oc:shareroot>
<oc:share-types></oc:share-types>
<d:getcontentlength></d:getcontentlength>
<oc:size></oc:size>
<d:getcontenttype></d:getcontenttype>
<oc:downloadURL></oc:downloadURL>
</d:prop>
<d:status>HTTP/1.1 404 Not Found</d:status>
</d:propstat>
</d:response>
</d:multistatus>
It still needs to change the response format for the internal link
PROPFINDrequest.
I think the intention for internal links was to have the /dav/public-files/ endpoint reply with a HTTP redirect (Status code 301 or 302) pointing the client to the correct location at /dav/files/<resourceid>.
It still needs to change the response format for the internal link
PROPFINDrequest.I think the intention for internal links was to have the
/dav/public-files/endpoint reply with a HTTP redirect (Status code 301 or 302) pointing the client to the correct location at/dav/files/<resourceid>.
Do you mean the redirect to the /dav/spaces/<resourceid> ?
@micbar @rhafer Based on @JammingBen suggestion I removed the WWW-Authenticate Basic header in case when unauthenticated clients accessing a password protected link.
Ok, fine for me.
https://github.com/owncloud/ocis/pull/8926 was merged