beforeGetFile trigger

[stevestencil]

Is your feature request related to a problem? Please describe.
With the addition of file triggers, the only one that is missing is beforeGetFile. Let's say that I want to restrict fetching a file to only the user who initially created it. Currently there is no way to do that since anyone with the file url can access it.

Describe the solution you'd like
Add a beforeGetFile file trigger so that an additional layer of security can be added when fetching files

Describe alternatives you've considered
None

Additional context
Currently anyone who has the file name/url can retrieve a file. Adding a beforeGetFile trigger will allow for additional file security. My plan is to use the beforeSaveFile and afterSaveFile triggers to keep track of files and who created them. I can then use the beforeGetFile to restrict access to only the files they have created. The challenge is there is no session token passed in when retrieving files. I have no problem tackling this feature request, but I would like to get feedback on the best way to approach this?

[mman]

This sounds like an interesting idea but it is hard to implement systematically since for example with S3 adapter the URL points directly towards S3 after upload and the file download does not go through the parse server, which is a good thing IMHO for performance reasons. Could probably work with GridFSAdapter.

[stevestencil]

If you're using direct access to your S3 adapter you are correct. The only way to implement this would be if you do not use direct access

[mtrezza]

I am all for beforeFindFile and afterFindFile triggers. I think this is a very valid feature request, in fact I just posted a SO question before finding this.

Of course direct access for S3 means that the 404's would have to be detected from the S3 server access logs, but that is something Parse Server doesn't have to account for.

[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.

[dsyrstad]

I'm all for this request. With parsed-based file URLs the way they are now, it is a security issue. Once someone has the URL, they have it forever and can access it without any kind of authentication or authorization.

[mtrezza]

@dsyrstad If it helps, it is possible to create temporary URLs, depending on how you store your files. For example, for AWS S3 there is an open feature request to support pre-signed URLs.

[dsyrstad]

@dsyrstad If it helps, it is possible to create temporary URLs, depending on how you store your files...

@mtrezza Are you saying a temp URL could be created in the file store adapter, or elsewhere?

[mtrezza]

The expiration would be managed by the storage service, but the Parse Server storage adapter would request the temporary URL from the service. I think this is already implemented in the Azure storage adapter, but if you want that for S3, you could continue the PR that already exists.

[dblythy]

It would be good to have an option for something like req.file.download = true so you can force files to download.

I'm happy to work on this, but I believe the only concern is it's impossible to determine req.user when files are accessed via a get request to a URL (as browsers don't pass in req headers for <img src="parsefilurl" />). Adding req.user would require some sort of FileObject class as well as tokens in the URL param to determine ID of user requesting the get.

Do you have any ideas @mtrezza?

[mtrezza]

I think Parse Server could restrict certain files to certain users while allowing anonymous downloads for other files.

• If you have an image that will be embedded on a website, you simply don't have to restrict it.
• If you a have a sensitive document then you can restrict it (and provide header auth info in the request).

Setting permission per file may be something that should really be done on the resource site. For example, if you store a file on AWS S3, you could use AWS IAM and link that to the Parse Server User class via an identity broker, so that you can reference S3 file permissions using Parse Server User IDs. That's the safest way, because it's on the lowest resource level, regardless from where the access request comes.

If we want to "fake" these storage permissions in Parse Server, we'd probably need a central list of files. Because a Parse File can be referenced in many places, but binding a permission to only one of many references doesn't make much sense. We could create a new internal class File and if a file should be restricted, add an entry there with the file pointer and a fileACL field. So every time a file is requested, a lookup happens in that class and the ACL is applied. Files would be compared by filename as their UID.

Btw, this File class is something we have also discussed for a file cleanup feature, so it would be a step into that direction.