On Drupal 7.23, entering into the cropping overlay, the generated image is missing. Looking into my firebug, I'm seeing 403 Forbidden on trying to access that URL.

Other Image Styles are working fine.. so, I get into my debugger and drill in to see what's happening.

Apparently, image_style_deliver() is returning MENU_ACCESS_DENIED because this logical test fails (line 820 of image.module):

$_GET[IMAGE_DERIVATIVE_TOKEN] === image_style_path_token($style['name'], $scheme . '://' . $target)

There is an override to this, setting image_allow_insecure_derivatives variable to true. This is obviously not going to be a good idea for everyone, as it opens the site up to denial-of-service attacks and such.

CommentFileSizeAuthor
#2 imagecrop-url_fix-7856515-2.patch1005 bytesreubenavery
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

reubenavery’s picture

reubenavery CreditAttribution: reubenavery commented

hmm.. apparently the URL being generated is faulty. the query string coming out is:
http://foo.bar/path/to/gif?itok=-Ci0HtW-?time=1379021786
that second question needs to be an amperstand. I changed it to one and reloaded and all is good.

reubenavery’s picture

reubenavery CreditAttribution: reubenavery commented
Status: Active » Needs review
FileSize
imagecrop-url_fix-7856515-2.patch1005 bytes

Found the problem.. here's a patch.

jsbalsera’s picture

jsbalsera
he/his
Primary language Spanish
Location Córdoba, Spain
CreditAttribution: jsbalsera commented

Hi!

Same problem here, I adapted your solution to 7.x-1.0-rc3 and it saved my day.

Thank you!

ianthomas_uk’s picture

ianthomas_uk
he/him
Primary language English
Location Brighton, UK
CreditAttribution: ianthomas_uk commented
Status: Needs review » Needs work

While the solution in the patch works, it seems overly complicated and fragile, as it is stripping the URL down to it's components and rebuilding it - hopefully in the same way that it was built before. At the very least it is not adding a port number to the URL, so could cause problems if people have development / testing environments set up on alternative ports. I think there's also a scenario where & and & get confused but I forget exactly how to trigger that so it may not apply in this instance.

Looking at the pre-patch code I think the problem is the assumption that having clean URLs enabled will mean the image URL won't have a query string and therefore needs a question mark added which is incorrect. Since we're already checking for the presence of a question mark I suggest just removing the code that checks the clean_url status.

ianthomas_uk’s picture

ianthomas_uk
he/him
Primary language English
Location Brighton, UK
CreditAttribution: ianthomas_uk commented

Actually, this looks like another example that should be added onto the patch in https://drupal.org/node/1924078 #9. I won't close this as a duplicate yet though, as at the moment the best thing to do is apply the patches from both issues (until someone writes a combined patch).

ianthomas_uk’s picture

ianthomas_uk
he/him
Primary language English
Location Brighton, UK
CreditAttribution: ianthomas_uk commented
Status: Needs work » Closed (duplicate)

This is actually incorporated in the fix in https://drupal.org/node/1924078 after all.