user_id in file management paths

[soxofaan]

The file management paths have user id in them:
https://open-eo.github.io/openeo-api/apireference/#tag/File-Management

• GET /files/{user_id}
• GET /files/{user_id}/{path}
• PUT /files/{user_id}/{path}
• DELETE /files/{user_id}/{path}

Why is that, given that the requests already require a bearer authorization header which should identify the user?

[flahn]

You are right. We have introduced the user_id as argument to enable sharing of data in the workspace. However this would only require GET /files/{user_id}/{path} to use the path parameter. And since we get URLs as results from the service and result endpoints that are shareable, we should consider dropping the user_id as a parameter in this case.
But maybe I'm missing something.

[m-mohr]

Indeed, the user_id in the path is meant mostly for sharing purposes in the future. This is because path is not unique (there could be two users uploading and sharing a test.txt). All other resources have IDs which should be unique across all users.

If this answers is sufficient, please close the issue. Otherwise let me know whether you like the parameter to be removed and why. Thank you.

[soxofaan]

ok, I understand.
I guess it is recommended for a client to use the authenticated user_id as default? Maybe this could be mentioned in the doc?

On the other hand (and maybe I am picking up old discussions that are a closed deal): as a user I don't expect to see files from other users, let alone other users being able to see my files.
If you look at Google Drive, Dropbox, S3, etc for example, users have their own personal "namespace" of paths, which they can not escape by just going up the folder hierarchy. File sharing in these systems also typically happens though a separate path/uri scheme.
But again, maybe I am not aware of reasons to make file sharing as simple as possible.

[m-mohr]

I guess it is recommended for a client to use the authenticated user_id as default?

Yes.

I'm open to removing the user id. It also depends on the decision we make for #135, I guess...

[m-mohr]

Let's drop it for now, will also make authentication easier as the client doesn't need to know the user id. Any concerns?

If the user ID gets removed, we need to remove

After authentication, Clients SHOULD request further details about the user from GET /me so that they can make requests to the /files/{user_id} endpoints.

from the API description twice.

[soxofaan]

I'm in favour of dropping it

[m-mohr]

Discussed on the dev telco today. Somewhat agreed on dropping the user_id, but several people (also VITO) raised that there's not enough experience yet with the /files/... endpoints yet. So there's a preference of dropping it, but before making this change maybe we wait for another month or so and then check back again.

[m-mohr]

For sharing, we could still add a public URL for each file to the GET /files endpoint later. So I don't see a real reason to keep it. => Removed user_id from spec.