Deprecate and remove `/cloud/user/signing-key` endpoint

[rhafer]

With #1191 we're getting one step closer to being able to remove the need to client side created signed urls.

Problem

• The signing-key endpoint is the last remaining endpoint offered by the ocs service in OpenCloud (not to be confused with the ocs service in reva). Removing it would mean we could delete the whole service
• The concept of client side signed urls has a few drawbacks
  • The secret used for signing the url leaks the server
  • The client is able to generate any signed url it likes
  • The client is in control of the lifetime of the signature
  • per-user secrets need to be managed and stored on the server side

Solution

Switch all remaining cases where signed urls are needed to be able to download things to use server generated signed urls. Currently client signed urls are used by web at least in these cases:

• Downloading files using the Download button in the web ui. This could be solved by just using the oc:downloadURL property added by proxy(sign_url_auth): Allow to verify server signed URLs #1191
• Downloading a directory using the archiver
• Downloading versions of files Deprecate and remove /cloud/user/signing-key endpoint #1197 (comment)
• ???

The other clients (desktop, ios, android) don't seem to be using the signing-key anywhere.

[rhafer]

@kulmann @AlexAndBear file downloads and the archiver are the only place I could find where the signing-key endpoint is still used. Do you know of any other?

For the archiver I guess we'd need to enhance the archiver service itself to be able to return a server signed url for downloading the archive.

[kulmann]

@kulmann @AlexAndBear file downloads and the archiver are the only place I could find where the signing-key endpoint is still used. Do you know of any other?

For the archiver I guess we'd need to enhance the archiver service itself to be able to return a server signed url for downloading the archive.

The new avatar URLs are also client side signed urls 🙈 @AlexAndBear could we use blobs with data urls here and download the avatars with authenticated requests?

[AlexAndBear]

The avatar urls are returned via graph endpoint (and stored as blobs) I don't think they don't have anything to do with this.

[rhafer]

I think the avatar stuff in web that still references the signing-key endpoint is something historic. The requests go to /dav/avatars/. We don't have anything like that in the OpenCloud server.

[JammingBen]

We also need to think about version downloads. Currently, the web client manually constructs the version URL (https://github.com/opencloud-eu/web/blob/v4.2.0/packages/web-client/src/webdav/getFileUrl.ts#L42) and then signs it. It would be nice if the server would also respond with a download URL when requesting versions via a PROPFIND on /dev/meta/... (given the downloadURL prop is being requested, of course).