-
-
Notifications
You must be signed in to change notification settings - Fork 85
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Objects uploaded with generateKey return incorrect locations #237
Comments
Thanks for opening this issue! |
What version of the adapter has this issue? Did you try different versions to see where this issues started to occur? |
I'm using v4.0 but best I can tell from the code inspection since it
appears to be related to a need to work around the parse-server
integration, this issue would pre-exist the new release.
|
@AdrianCurtin were you able to gain any insight already as to where the issue comes from? |
I mean it's definitively because location returned by getFileLocation and the location used in createFile is discarded. getFileLocation should return the unmodified (potentially signed) url or key, and so including generateKey in that component does not make specific sense to me. In any case it cannot know what the generated key will be necessarily) There's one fix in parse-server that would look like this. Original
Updated
I don't know if there's a specific one for s3 adapter that could be made and I don't know how this would affect other file adapters |
I opened a PR here for s3-adapter and a PR here for parse-server This fix will require both of these to work, but this PR can be merged in advance of the parse-server functionality with no ill effects |
I think the S3 PR should be merged first, so that the Parse Server tests with the new adapter can pass? |
I think it also makes sense to add a test later (which will fail on the current parse server) basically for situations with generateKey, the filename (or url) returned from FilesController.createFile contains the new key. Also i note that the preserve filenames for this does not need to be enabled or disabled. generateKey for instance could strip the random hex string, or prepend /uploads/ to the string etc. This basically makes it possible to use s3 directories. @mtrezza , do you think it would make sense to give generatekey access to different attributes apart from filename?, either contentType or options for instance. That way keys could be assigned filenames (or directories) according to content type. I also like the option of giving it the application Id via the config (if provided), then in theory the user could do something like (if they set up the generate key appropriately). s3://prefix/app-id/images/date/upload.jpg |
I added it to the last commit (without the config argument) and (without giving direct access to data) |
From parse-server\lib\Controllers\FilesController.js - line 32
Location is a const fed in from getFileLocation, but getFileLocation will always return the location before key generation occurs.
object location created by this.adpter.createFile as an output argument is discarded.
Additionally, getFileLocation will return the presigned item based on the old filename rather than the new file name.
Ex:
getFileLocation will return the full (optionally presignedUrl) or "https://${this._bucket}.s3.amazonaws.com/${this._bucketPrefix}${fileName}" where fileName is file.jpeg
However createFile will instead return a location of
https://${this._bucket}.s3.${this._region}.amazonaws.com/this._bucketPrefix + this._generateKey(filename)
Until this issue is fixed, generateKey should be considered to be non-functional. Either the filename should be rewritten with the generated Key prior to getFileLocation (and the createFile call should not generate a new key) or the FilesController.js should be wrapped to account for this.
The text was updated successfully, but these errors were encountered: