[MGNLIMG-134] STK image variations should be multi-site aware Created: 08/Jul/14  Updated: 19/May/22  Resolved: 19/May/22

Status: Closed
Project: Imaging
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Neutral
Reporter: Edgar Vonk Assignee: Unassigned
Resolution: Won't Do Votes: 0
Labels: multisite, stk
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Date of First Response:

 Description   

As Richard has explained quite well in this forum post the STK imaging support is currently not multi-site aware.

This causes issues related to security but in our case because of a complex Apache virtual host set-up for our multi-site Magnolia implementation it causes the image variations not to work at all. The problem is that the image variation URLs do not include the site name as all other resource URLs do. The image variations URLs look like:

${contextPath}/.imaging/${generatorName}/${workspace}/${imagePath}

but we need them to be:

${contextPath}/<sitename>/.imaging/${generatorName}/${workspace}/${imagePath}

Like Fabrice we will solve this issue by writing our own multi-site aware STKImagingSupport class.

I think it would be good if the STK imaging support became multi-site aware to solve these issues?

For completeness this is Richard's 2 cents about it from the forum:

the imaging module could be described as "not multisite capable". I would say the current design of the imaging module is "parallel" to the multisite concept for the website workspace.

The mode of operation is something like this: /.imaging/<generator-name>/** trigger the imaging module and invoke a specific generator. It is then up to the generator how the rest of the URL and other parameters are handled, and to resolve an image. The concept of site doesn't really enter into it until after the STK generator is invoked, when it uses the site to resolve the theme, to find the defined variations.
In addition, the imaging module caches such images in the imaging workspace. The imaging cache is also not "multisite capable", nor does it evaluate permissions in any special way.

I agree with you that this behavior could be viewed as a bug, in the sense that it is a "common problem" which many users face when implementing "secured areas" in websites, or in co-hosting situations.

Possible improvements might include:

  • tie security into the cache (eg something like reading from imaging cache requires read permissions on original image)
  • make the stk generator multi-site aware and tie in the cross-site security (maybe fabrice' solution is a basis for this)
  • consider how these concepts mesh with the site variations, personalization, vanity URLs and URL shortening features


 Comments   
Comment by Roman Kovařík [ 19/May/22 ]

Hello,

This ticket is now marked as closed due to one of the following reasons:

  • A long period of inactivity
  • Uses an old or Beta version of an application, module, or framework that we no longer support
  • The issue is no longer reproducible or has been fixed in later versions

If you are still facing a problem or consider this issue still relevant, please feel free to re-open the ticket and we will reach out to you.

Thank you,
The Magnolia Team

Generated at Mon Feb 12 02:12:37 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.