[MGNLIMG-117] Image variations do not respect security applied to original image storage location Created: 08/Oct/13  Updated: 19/May/22  Resolved: 19/May/22

Status: Closed
Project: Imaging
Component/s: image operations
Affects Version/s: 2.2
Fix Version/s: 2.x, 3.0.x

Type: Bug Priority: Critical
Reporter: Lars Fischer Assignee: Unassigned
Resolution: Won't Do Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Tested with a Magnolia 4.5.12 EE bundle


Attachments: PNG File img-access.png    
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)
Bug DoR:
[ ]* Steps to reproduce, expected, and actual results filled
[ ]* Affected version filled
Date of First Response:

 Description   

Use case: On a protected page (login required) the referenced images stored in the DMS should also not be accessible, even if the direct URL of the image is known.

Images are stored in the DMS under a protected path not accessible for anonymous access.

To protect these specific images from anonymous access, the anonymous role is denied access to that path in the DMS (using ACL settings).

This does not work because image variations created automatically store the referenced images in a different path like:

http://localhost:8080/magnoliaPublic/.imaging/stk/pop/content/dms/demo-project/protected/homer1/document/homer1.jpg

The path above is not protected by the previously defined ACL so the image is accessible using it's URL directly.

Also, in an STK teaser located above the path with the page containing the protected page/image the image might be shown as variation automatically because it is served from the images workspace.

See attachment for an example where the protected image is shown for an anonymous user by the STK component.

In conclusion, the permissions for DMS/DAM/anything else should be transitively applied to the content in imaging.



 Comments   
Comment by Milan Divilek [ 14/Oct/13 ]

When I deny access to any image in DMS/DAM by adding appropriate ACL. This also affect image variations in imaging repository, because ImagingServlet firstly try get image node from DMS/DAM during setting of ParameterProvider.
Similarly to uploaded images, but there you should set deny access for protected page in website repository.

Comment by Magnolia International [ 05/Dec/13 ]

mdivilek, that is only true on first generation (and even then, I'd have thought this was using system context). If the image is already generated/stored, then the source image's ACLs aren't checked, IIRC.

Comment by Milan Divilek [ 05/Dec/13 ]

gjoseph, I just quickly tested it on demopublic45 and it's also when image is already generated.

Setting of ParameterProvider is done also when image is already generated. It's try to get node from DMS/DAM so you will get javax.jcr.PathNotFoundException(because javax.jcr.Node#getNode doesn't throw AccessDeniedException). ImagingServlet then doesn't handle with it gracefully you get ugly HTTP Status 500, but it's not serve you the image. It would be nice to improve this handling.

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:26 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.