Uploaded image for project: 'Imaging'
  1. Imaging
  2. MGNLIMG-134

STK image variations should be multi-site aware

    XMLWordPrintable

Details

    • Improvement
    • Resolution: Won't Do
    • Neutral
    • None
    • None
    • None

    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

      Checklists

        Acceptance criteria

        Attachments

          Activity

            People

              Unassigned Unassigned
              edgar Edgar Vonk
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Checklists

                  Task DoD