Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
If you add (upload) an image trough the CK editor and:
- That image contains a space in its filename
- And you have selected the Basic HTML format
- And that Basic HTML format has the "Restrict images to this site" filter enabled
Then the rendered node will have a blocked image icon and the text that the image is blocked due to security reasons.
This caused by the _filter_html_image_secure_process() function.
It searches trough the DOM in the HTML for image tags, extract the src of them and uses that path to see if it is an internal URL and if the image exists.
The HTML has the rawurl encoded version of the filename. This means that the space is in the src rendered as "%20".
Using that path to get the imagesize breaks because the file is not found.
Comments
Comment #1
zero2one CreditAttribution: zero2one commentedI created a patch for this:
It first passes the rawurl encoded src of the image trough the rawurldecode function.
And uses the result to get the image size.
Comment #2
larowlanThanks, can you also add this scenario to the tests for that filter?
Comment #3
zero2one CreditAttribution: zero2one commentedAdded the scenario's to the tests.
Please review the test code.
Comment #4
larowlanThere's some trailing whitespace here
We don't normally reference fixes in comments, can you remove this @see?
Can we get two versions of the patch, one that is 'tests only' i.e. doesn't include the fix.
And a second one that is tests + fix.
If you upload them to the same comment, with the tests only one first, we should see 'fail' then 'pass' for the patches.
This give the committer confidence that a) we've found the problem b) we have a test so it never breaks again c) we have a fix
Thanks!
Comment #5
larowlanTag can go, we have tests now
Comment #6
zero2one CreditAttribution: zero2one commentedThis are the patches:
I also removed the whitespace.
Comment #7
larowlanJust nitpicks now
(nitpick) needs a . on end of line as per coding standards (see node/1354)
I think there might be a function to do this, basepath perhaps?
no need for indent/alignment I think
Comment #8
larowlancrosspost
Comment #9
zero2one CreditAttribution: zero2one commentedI refactored the code to match the standards.
I removed the code to get the base path, the file is in stored in the root of the public folder (public://) anyway.
Comment #11
zero2one CreditAttribution: zero2one commentedpublic:// worked locally but not on the d.o test bot.
Reverted the code to a string_replace. It's less environment dependent.
Comment #12
zero2one CreditAttribution: zero2one commentedChanged issue status
Comment #13
zero2one CreditAttribution: zero2one commentedRemoved the change of the file mode of the settings.php file from the patch.
Comment #14
Wim LeersI asked for a reroll in person of #13 because it contained an inappropriate permission change.
Now the patch is perfect. Nice and simple, additional test coverage to prevent regressions, a fail and pass patch to prove it works.
Thanks! :)
Comment #15
Wim Leers.
Comment #16
webchickAwesome work!
Committed and pushed to 8.x. Thanks!
Comment #18
hass CreditAttribution: hass commented#2125301: %20 in image file names triggers the "local images only" filter
Comment #19
Wim Leers#18 this filter does not exist in Drupal 7. I think you'll want to open an issue for https://drupal.org/project/filter_html_image_secure.
Comment #20
webchickYep.
Comment #21
hass CreditAttribution: hass commentedIs this what d.o use?
Comment #22
tvn CreditAttribution: tvn commentedYes, D.o is using https://drupal.org/project/filter_html_image_secure
Comment #23
mgiffordThis is the issue that is affecting d.o #2125301: %20 in image file names triggers the "local images only" filter for future reference.