[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: |
|
| 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: 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. |
| 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:
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, |