discuss UploadedByUserID about hasura-storage

[altschuler]

otherwise I can't see how you could verify that the user was actually the uploader of the file they're associating (in step 3).

Since the file id is generated by the server and is pretty much non-guessable, I would say it's safe to trust the data if the user adds a file id (and the user id is added as a Hasura preset) in step 3.

Since the file id would have to be selectable by the user, there's a good chance they could find some other random file id (by looking at data in the application), and thus could mark themselves as uploader of that. Could be somewhat mitigated by having a unique key on the file id in the lookup/relation table, but it's still fragile (maybe the relation wasn't created for some other user's file because they lost connection and it's not - as you mentioned - transactional).

[dbarrosop]

we decided users will set this as they please

[altschuler]

Might be worth documenting this in the storage docs, and noting that one can use a column preset for the field is desired. I think it's fair to say that it's expected that it's set automatically since the column is there at all by default :)

[elitan]

How about we deprecate the uploadedByUserID field and let users implement who's uploaded what in their own tables.

A process like this:

1. Upload file
2. Get returned file id
3. Insert file id, together with your user id as a preset (x-hasura-user-id), in your own custom table

In step 3 developers can use FKs, Hasura Relationships, and Insert Presets (x-hasura-user-id) on the user_id column.

The downside is that this process would not be transactional.

[altschuler]

You'd have to do that as a Hasura event on the files table, otherwise I can't see how you could verify that the user was actually the uploader of the file they're associating (in step 3). A bit cumbersome I think.

What was the rationale behind not storing the uploader id by default? Seems like a very useful feature.

[dbarrosop]

I think this is up to the users and their applications. The field itself has no meaning or use to hasura-storage. A user may need an "uploadedBy" field or it might not, or it might need something else. For instance, if you were working with user profiles the only thing you would need is a "profile_pic_id" pointing to a file and that would most likely be part of your "profiles" table, you really don't need/care about the "uploadedByUserID" field. I think the bottomline is hasura-storage should care about the things it needs, everything else is business logic to be implemented by the user. Alternatively, if it turns out that having some form of metadata attached to each files, we could add a metadata field completely managed by the user of type jsonb and deprecate the field in favor of this generic one.

[nunopato]

I think the metadata field is what makes more sense here and we already have it in hasura auth as jsonb (https://github.com/nhost/hasura-auth/blob/main/migrations/00002_custom-user-fields.sql#L4).

[elitan]

otherwise I can't see how you could verify that the user was actually the uploader of the file they're associating (in step 3).

Since the file id is generated by the server and is pretty much non-guessable, I would say it's safe to trust the data if the user adds a file id (and the user id is added as a Hasura preset) in step 3.

What was the rationale behind not storing the uploader id by default?

It's more about decoupling Hasura Auth and Hasura Storage. We've already backed away from having an FK between the two tables (storage.files and auth.users). The reason we removed the FK was that we wanted Hasura Storage to be able to run independently of Hasura Auth.

---

I don't see how a metadata column would solve the problem related to uploaded_by_user_id. The metadata JSON column can not be populated by a Hasura preset (x-hasura-user-id).

[elitan]

Since the file id would have to be selectable by the user, there's a good chance they could find some other random file id (by looking at data in the application), and thus could mark themselves as uploader of that.

I'm not sure I understand this scenario. Could you elaborate?

Yea, the only issue I see with my initial proposed solution is, that it's not transactional.

[dbarrosop]

We had a chat internally and we decided to deprecate the field and instead document alternative ways of implementing this. The rationale is that, while this is useful, it is irrelevant for hasura-storage itself and we'd prefer to keep it lean and simple so providing simple instructions to implement this functionality for applications that need it feels like the right trade-off. Another big reason is that we don't want to introduce any dependencies between hasura-storage and hasura-auth (hence why the field isn't used).

I will leave this issue open to track the proposed solution and get feedback from users.

Note: notice we are not removing the field but we will document it as "deprecated" so users shoudln't expect their applications to break any time soon if they are using the field but they should start considering alternatives as eventually we will remove it entirely.

[beepsoft]

uploadedByUserID is still not mentioned in the docs as deprecated. What is its status now?

I don't really understand this issue about decoupling from auth. A storage.files record is practically already coupled with auth via the Hasura permissions one sets on the storage.files. Having relations of files to users in another table just to be able to add some other permissions based on the user who uploaded the file seems like a burden for developers. Not that it is not doable, but doesn't seem natural and as Johan mentioned, it won't be transactional.

Of course, I already have a couple of relations to my tables where the uploaded file is used and these can be/will be used for permission checks as well. But, for example, to list all files a user uploaded, querying by uploadedByUserID could be much simpler and effective than navigating to all the joined tables and checking user equality.

What would be a use case for hasura-storage on its own without hasura-auth or the nhost stack in general?

So, if it not a problem for the rest of the nhost project I would appreciate keeping and automatically setting the uploadedByUserID field by hasura-storage.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[iamkhalidbashir]

otherwise I can't see how you could verify that the user was actually the uploader of the file they're associating (in step 3).

Since the file id is generated by the server and is pretty much non-guessable, I would say it's safe to trust the data if the user adds a file id (and the user id is added as a Hasura preset) in step 3.

Since the file id would have to be selectable by the user, there's a good chance they could find some other random file id (by looking at data in the application), and thus could mark themselves as uploader of that. Could be somewhat mitigated by having a unique key on the file id in the lookup/relation table, but it's still fragile (maybe the relation wasn't created for some other user's file because they lost connection and it's not - as you mentioned - transactional).

This is a very important security issue. If a user can get access to an ID of a file (which wasn't uploaded by him) then he can essentially use that id to get access to that file on his own account

[iamkhalidbashir]

So, if it not a problem for the rest of the nhost project I would appreciate keeping and automatically setting the uploadedByUserID field by hasura-storage.

+1

[dbarrosop]

This is a very important security issue. If a user can get access to an ID of a file (which wasn't uploaded by him) then he can essentially use that id to get access to that file on his own account

While I understand the sentiment, that has nothing to do with hasura-storage. That is a security issue in your application. We have stated several times we don't support that field and that users should track ownership in the way that makes sense in their application. Then you can use that tracking to set permissions if that's what you need.

I understand this solution with the column is a convenient mechanism for some users but unfortunately it isn't generic enough and it adds a dependency to hasura-auth we don't want to have.