Replace reserved chars in filenames #138
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
As the tus endpoint breaks with 400 when uploading files with certain characters within them, the fileName is cleaned from those malfunctioning characters before adding it to the Uppy store (and eventually uploading them, as auto resume is activated). The characters to be replaced were chosen based on a manual test that i conducted - while i could not produce a file containing a forward slash on my linux machine, all other characters have proven to break the endpoint. Maybe i missed a character, then it will have to be added to the list. The fix revealed another bug - file names containing a colon : now broke the frontend, because the colon is used as a separator in getFileInfo. As the conversion (from object to fileString and vice versa) is not needed but is a remainder from the Uppy refactoring (as far as i could understand it), it is dropped altogether, and the file object is directly passed into DpUploadFile.
salisdemos
requested changes
Mar 29, 2023
Comment on lines
127
to
131
| /* | ||
| * For reasons i could not figure out, the for loop was needed here | ||
| * to reliably access the item that is looped over. When using forEach, | ||
| * strangely it always held the value of currentFile. | ||
| */ |
There was a problem hiding this comment.
since its totally fine to use a for-loop, I suggest to drop the comment.
There was a problem hiding this comment.
but in case somebody wants to optimize it, they'll be warned, if we leave the comment there.
There was a problem hiding this comment.
Actually I am against that. Then we have to argue all our code in comments....
There was a problem hiding this comment.
ok, removed in 5c6ee11
salisdemos
approved these changes
Mar 29, 2023
2 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Ticket: https://yaits.demos-deutschland.de/T31971
As the tus endpoint breaks with 400 when uploading files with certain characters within them, the fileName is cleaned from those malfunctioning characters before adding it to the Uppy store (and eventually uploading them, as auto resume is activated).
The characters to be replaced were chosen based on a manual test that i conducted - while i could not produce a file containing a forward slash on my linux machine, all other characters have proven to break the endpoint. Maybe i missed a character, then it will have to be added to the list.
The fix actually only changes the file name in the outermost
file.name, and withinfile.meta.name, whereas it leaves the original file name withindata.File.name(which is an instance of the File API and also preserves the original name within its prototype). Somehow this leads to the unchanged file name being displayed correctly after uploading has finished. As such, there can be said that the bug has not been understood from a backend perspective.The fix revealed another bug - file names containing a colon : now broke the frontend, because the colon is used as a separator in getFileInfo. As the conversion (from object to fileString and vice versa) is not needed but is a remainder from the Uppy refactoring (as far as i could understand it), it is dropped altogether, and the file object is directly passed into DpUploadFile.