New anti-DoS measure breaks displaying images in WYSIWYG content [#1923834]

Setup:
In our install we have content created with CKeditor (7.x-1.12) containing images uploaded by Media module (7.x-2.0-unstable7) inside the WYSIWYG editor.
This leads to the full URL to the image getting embedded into the HTML generated by the WYSIWYG editor (which is an unrelated problem in itself, see #1352182: Media assets should have relative paths for wysiwyg editors).

Problem:
As such, the URL (saved in the HTML in field_data_fieldname.fieldname_value) is not getting updated when upgrading to Drupal 7.20.
As such, it does not contain the now required "itok=token".
As such, the image is not displayed any more.

Question:
Is there any way to solve this problem apart from
a) editing all the links in the database tables
or
b) disabling the new anti-DOS feature in settings.php

Comments

Comment #1

swentel CreditAttribution: swentel commented 21 February 2013 at 19:50

See the release notes here at the end http://drupal.org/drupal-7.20-release-notes

Comment #2

David_Rothstein CreditAttribution: David_Rothstein commented 21 February 2013 at 22:25

I wasn't able to reproduce this. It is true that the URL is stored without the token, but it shouldn't matter because the image has already been generated at that point. The token is only needed the first time it's viewed (in order to generate it in the filesystem). After that it's just a regular image file.

Do you have a more specific set of steps to reproduce this problem? It seems like somehow you'd have to have inserted a URL to an image in the WYSIWYG without that image ever being displayed anywhere first... which in theory is possible, but seems like it would be hard to achieve in practice, and I haven't figured out how to reproduce it yet.

Comment #3

David_Rothstein CreditAttribution: David_Rothstein commented 24 February 2013 at 21:34

Status:

Active

» Postponed (maintainer needs more info)

Comment #4

j4h8 CreditAttribution: j4h8 commented 25 February 2013 at 09:28

Thanks for following up on this and sorry for my late answer.

The image is indeed in the filesystem, but we use the "private files" configuration.
(The URL is e.g. $DOMAIN/system/files/styles/full_wysiwyg_size/private/image.png)

Could our problem be related to this fact?

Comment #5

David_Rothstein CreditAttribution: David_Rothstein commented 25 February 2013 at 22:24

There are some automated tests for private files that should have caught any issues here, but I went ahead and tried it manually and private files worked for me on a local setup after upgrading to Drupal 7.20.

Just to make sure, you are saying that within your private files directory, there is a file at styles/full_wysiwyg_size/private/image.png? But visiting $DOMAIN/system/files/styles/full_wysiwyg_size/private/image.png still gives access denied?

If so, I don't see how it could be directly related to the Drupal 7.20 upgrade... However, two questions:

What modules do you have installed that do either node access or field access and might be blocking access to that URL? For example, are you using Field Permissions?
Have you tried the patch at #1923554: New anti-DoS measure breaks for some file URIs (or other patches linked to in the release notes, depending on what modules you're using)? I don't think it's related, but it wouldn't hurt to try.