Drupal File Upload Renames Square Bracket Characters
Information technology looks like the work done on #2139287: Renaming 'File' uploads with tokens is not yet available for D8.
A short description of the effect is that information technology would exist overnice to be able to rename files uploaded via a webform by using tokens.
Comment | File | Size | Writer |
---|---|---|---|
#28 | Screen Shot 2018-12-xix at 4.45.45 PM.png | 24.12 KB | jrockowitz |
#17 | interdiff-2941286-fourteen-16.txt | 477 bytes | bserem |
#17 | 2941286-file-renaming-16.patch | 22.74 KB | bserem |
| |||
#13 | interdiff-eleven-13.txt | 4.27 KB | bucefal91 |
#thirteen | 2941286-file-renaming-xiii.patch | 22.68 KB | bucefal91 |
|
Support from Acquia helps fund testing for Drupal
Source: https://www.drupal.org/project/webform/issues/2941286
Comments
Jacob, if y'all similar, I can take this ane. As far as I can run into the following should exist done:
WebformManagedFileBase
(and all its children) to specify a destinationJust one dubiety: I would like to propose to unify the concept of "destination binder" and the "destination proper noun" to keep it simpler. Then the config that controls which folder and nether which name the file is saved is a single one. One example would look:
webforms/[webform_submission:webform:id]/[webform_submission:series]/[webform_submission:first_name]
. Then it would contain all but the scheme (public vs private, which is already controlled separately) and without the extension (since nobody would always want to change a file extension).Does it audio ok?
@bucefal91 Feel costless to take on this job and reassign this ticket to yourself.
It is very important that we don't let people customize the
webforms/[webform_submission:webform:id]/[webform_submission:serial]/
path because it is used by the CSV export to include uploaded files. This path design also prevents whatever filename collisions.We merely want to add together the ability to enter a custom filename with token support.
What do you think the new property should be called?
Probably #file_name is fine.
How do we handle multiple file uploads?
We might accept to autoincrement or disable file renaming.
Here's the business concern logic hammered. I all the same wanna practise a few things:
WebformManagedFileBase
.I've basically introduced a new protected method which determines the destination URI for a merely uploaded file and placed all the related logic into information technology (thus offloading a little bit the
::postSave()
).Tested manually:
somefile.txt
,somefile_0.txt
, and so forthI am throwing this patch generally to see if anyone wanna try it and to see what test bot says.
Dependency injection is added in this patch throughout the
WebformManagedFileBase
class. Over again I wanna confirm testbot likes it.I didn't account for the fact that file-based elements have soft dependency on file module in my concluding patch.
This patch is close to the final. It includes the new functionality and the new feature is also covered past Simpletests. Namely, if you go to edit any file-based webform element you will see a checkbox "Rename file" and if you enable it, you volition see a text field where you tin specify tokenized filename.
There is just 1 question I wanna bring up: is information technology OK to give capricious (anonymous) users ability to literally command filename? The user cannot jailbreak the scheme (public/individual) nor he can change the extension. Merely he can inject whatsoever symbol into filename. By itself from PHP point of view there is probably no injure, just information technology may be hurtful on the filesystem level or any other post-processing which might be there on height of a webform submission (emails, exporters, etc). Well, frankly, I am kind of scared to requite such level of control. So I vote in favor of allowing this filename only if the sanitization checkbox is enabled. (Note: this enforcement is not even so enabled in the patch I am attaching).
Below is some general code related feedback and compliments. I will have time to fully test the patch next week.
Delight add descriptions since Drupal's mode checker is going to be asking for them.
This change is going to conflict with #2941471: Setting a Managed file element'southward file size to the aforementioned as the default does not save the setting to config, results in other environments having incorrect setting. We should probably commit that much simpler patch outset.
Thanks for calculation the exam form it will make it really easy for people to review this patch
Hey! :)
your #one is addressed in this new patch.
As far as #2 - yeah, allow'south commit the other patch first and and so I will just post a re-ringlet hither resolving the disharmonize.
I shifted the pending question into the main ticket description so we do not overlook it.
Since every form element tin can be edited via YAML it is very important to go along the backdrop equally unproblematic equally possible.
So instead of storing...
We should just store...
Can we merge the #file_name_pattern property into the #file_name property.
Can you try using the new webform_checkbox_value element which I just committed via #2941740: Provide a checkbox value input.
The form element would get...
Permit's use 'Rename files' every bit the characterization since multiple files volition be renamed.
This would need to but look for and use the #file_name holding.
I don't call up we should crave 'Sanitize file name' to be checked just we should conditionally display an inline warning when 'Rename files' is checked and not 'Sanitize file name'.
Jacob, your feedback is fully incorporated. Additionally I have rebased my local branch against latest viii.x-5.x as there was a disharmonize. I made the warning bulletin read: For security reasons we propose to use Rename files renaming along with the Sanitize file proper noun option. -- seems like a reasonable one to me :)
Equally far as I am concerned, I deem it commit set up :)
First impressions are ok, I'd similar to say that allowing larger values on the rename pattern text field makes sense to me, since this is field where tokens will be used, and it is quite like shooting fish in a barrel to reach the limit if it is a pocket-sized ane.
I was expecting this to be really big because it was not limited, merely information technology wasn't, so I went this:
Other than that I can verify that the patch works.
Attached is an improved patch file and the interdiff.
Thanks @bucefal91 for the work!
PS: the patch from 13 is RTBC by me.
The improvements in xiv are modest, merely lets expect for someone to cheque them before we change the issue status.
@bserem Your point almost the #maxlength is a valid and the #maxlength should be set to Nothing which volition let for an unlimited number of characters/tokens.
Thank you for the tip! New patches on comment above
I besides back up the improvement from #17. :)
@bserem @bucefal91 I don't have fourth dimension to review the patch but it looks fine.
If you both feel this is RTBC then @bucefal91 please write a simple change notice and commit the patch.
Yoohoo! :) My 1st commit into the module :) The patch #17 just landed.
Well done @bucefal91!
Excellent work
Comment #26
GiorgosK
Chios, Greece 🇬🇷
Credit Attribution: GiorgosK commented
very prissy work, very much needed
have one question how do you rename on multi value field ?
lets say I take a field
attach
and the files submitted arefile1.pdf
file2.doc
and the rename blueprint is set to
[webform_submission:values:attach]-[current-engagement:raw]
then I will get 2 files names every bit such
file2-1533114159.pdf
file2-1533114159.md
only this renaming can create problem and should exist considered a issues
or am I using the filename token wrong ?
is there a token for each filename ?
In #12, jrockowitz writes:
However, we are seeing this message in the contrary situation--when sanitize is checked and rename is unchecked. Is this intentional? Is it actually a security issue to sanitize without renaming? Is it better to not sanitize or rename at all? In the latter situation, we aren't seeing whatever warning.
We're training our customers to utilise this grade and the "security" message worries them. The rename option requires them to write a regex design. Training them to use regex is probably not possible.. nosotros might opt to write a patch to remove this message from the code instead...
Below is the warning that is displayed when 'Rename files' is checked and 'Sanitize file name' is unchecked.
This is not truthful. The rename selection but optionally supports tokens. This is why the file name should be sanitized because tokens can incorporate any blazon of value.