Add a flag indicating whether the server should add a hash before all file names

[GabrielLomba]

Is your feature request related to a problem? Please describe.
I believe adding a hash before every file name can be made optional due to some use cases. For instance, me and my colleagues started working with a custom S3 server, using the S3 Files Adapter and, in our use case, we wanted to save files in a url that followed a certain unique pattern but the hash would not allow us to do it gracefully. We have a few options, such as the bucket prefix in the S3 Files Adapter, but in our case, it would not work because our prefix is built dinamically and the server always adds the hash here. We ended up forking the adapter and removing the hash before using the S3 to actually save it.

Describe the solution you'd like
We could add a flag (maybe addFileHash?) to indicate whether or not the hash should be added to both the Parse.Files name and urls. I've taken a look in the source code and I believe it should be relatively simple to implement this feature. I could do a PR, if it makes sense.

I've searched the docs and could not find such an option. I'm all ears to other solutions!

[georgesjamous]

I think its a valid suggestion

[flovilmart]

save files in a url that followed a certain unique pattern but the hash would not allow us to do it gracefully.

What kind of unique pattern? Do you want to store them in a particular folder, use a common prefix?

The hash is there as it is highly possible that the clients will always use the same file name, for reasons (like you need to provide a file name, that may not be unique), therefore file uploads will overwrite each others.

With the random string prefix, it guarantees that no file will ever overwrite eachothers.

We ended up forking the adapter and removing the hash before using the S3 to actually save it.

This is a reasonable alternative, the length of the hash is constant so I'm fine not changing and maintaining an alternate version on this repository, UNLESS this is really necessary.

[GabrielLomba]

What kind of unique pattern? Do you want to store them in a particular folder, use a common prefix?

An unique pattern based on some information that will be unique for each file. Something like {UUID}/{ENTITY_ID}/{ENTITY_FIELD}.{FILE_EXTENSION}. This url is built dinamically.

The hash is there as it is highly possible that the clients will always use the same file name, for reasons (like you need to provide a file name, that may not be unique), therefore file uploads will overwrite each others.

I know. I was thinking about adding this flag and setting its default to true. That way, it would not break any existing code and it would offer the option to not add the hash to the user, making the server more configurable. We could assume that, if a user sets this flag to false, he knows that the file names will have to be unique (could be stated in the docs too).

[flovilmart]

If I understand correclty, then this is not a random hash removal that you need but still you need your custom code in the adapter to generate your full pattern right? So removing the 'hash' from parse-server just help you remove a single line that strips the hash in your code.

In this sense, I don'T believe we should alter the code here in the way you suggest as it doesn't really help anyone. The hash is a constant length string.

[JacobJT]

My only complaint with the hash is that you can't search for files easily, since AWS only offers prefix search and the hash is obviously the prefix.

That being said, it's minor, and the salt provides an efficiency that most users would be hurt with losing. On top of the avoidance of overwrites, S3 can pull files way more efficiently due to how it pulls blocks from storage. I.e. if you were to prefix file names with dates, you're going to have tons of collisions between the first handful of characters in your file name, so it's going to take S3 a lot longer to find the right one. With the salted name, there are likely to be very few files that match the first few characters. Your specific use case doesn't appear to be affected by this, since it's using the UUID, but someone whose file name format is profilePicture${user.id} will have a bad time.

[GabrielLomba]

I believe I have expressed myself incorrectly. Our database is organized in a way that UUID uniquely identifies a class of entities. Therefore, by accessing the prefix UUID in the S3, we'd be able to retrieve all files for a certain class of entities, which would give us a way to organize the files.

So removing the 'hash' from parse-server just help you remove a single line that strips the hash in your code.

Actually, it is the only line we added to the forked S3 Adapter, as we are already passing the file name with all the data (UUID, ENTITY_ID, etc). So, allowing to remove this would remove our need for the fork entirely.

That being said, it's minor, and the salt provides an efficiency that most users would be hurt with losing.

I definitely understand that most users would want the hash to stay as it eases the storage and that is why I said that we maybe could add a flag and set its default to true (i.e. the hash would be added by default).

[flovilmart]

Ok, can you make a PR for this with the according tests and configuration?

[GabrielLomba]

@flovilmart Just did the PR (#4915).