Could this be enabled per role or per style like in Drupal 6 imagecache?

Comments

RobLoach’s picture

RobLoach
he/him
CreditAttribution: RobLoach commented

Not sure we could do this on a per-role basis, since the same images are loaded across requests and we are not sure which images each user is loading. The variable to toggle it is also global static state, which probably cannot be toggled live between requests. Am I understanding what you're asking here? What is the final goal?

ufku’s picture

ufku CreditAttribution: ufku commented
Title: Enable insecure derivatives by role » Enable insecure image derivatives by role
Project: Image Allow Insecure Derivatives » Drupal core
Version: 7.x-1.x-dev » 8.x-dev
Component: Miscellaneous » image system

I'm looking for a solution to IMCE's broken thumbnail preview feature that creates thumbnails on client side with a provided style name.

I thought some trusted roles could be given permission to create derivatives like in D6. But it seems the issue belongs to core which needs regular permission definitions for this.

jcisio’s picture

jcisio CreditAttribution: jcisio commented

I think 99% of the sites want insecure derivatives for anonymous... If not, there will be a problem when image styles are flushed.

greggles’s picture

greggles
he/him
Primary language English
Location Denver, Colorado, USA
CreditAttribution: greggles commented

Note my comment on this idea at #1934498-53: Allow the image style 'itok' token to be suppressed in image derivative URLs. It has some merit, but the flaws should be noted.

ufku’s picture

ufku CreditAttribution: ufku commented

In order not to pollute the other issue I'm asking here. Why isn't there any SA for Drupal 6 imagecache? Isn't it vulnerable?

greggles’s picture

greggles
he/him
Primary language English
Location Denver, Colorado, USA
CreditAttribution: greggles commented

@ufku - sure thing. So, Imagecache for 6.x doesn't have a stable release. The SA policy is not to do an SA for modules without a stable release. The imagecache 6.x maintainers were aware of this issue from basically the same time as the Drupal Security Team (they were invited to help with it). Pwolanin and scor from the security team did work on a 6.x port of the fix at #1922812: Protection against DOS SA-CORE-2013-002 - Drupal core - Denial of service.

ufku’s picture

ufku CreditAttribution: ufku commented
Status: Active » Closed (won't fix)

@greggles: thanks for the explanation.
Marking this as won't fix. I'll follow #1934498.