[MGNLDAM-611]  ACL's not respected for Assets Created: 13/Aug/15  Updated: 15/Apr/16  Resolved: 12/Nov/15

Status: Closed
Project: Magnolia DAM Module
Component/s: DAM JCR Provider
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Neutral
Reporter: Mariusz Chruscielewski Assignee: Sang Ngo Huu
Resolution: Cannot Reproduce Votes: 1
Labels: security, support
Remaining Estimate: 2.25d
Time Spent: 1.75d
Original Estimate: 4d

Issue Links:
Relates
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:
Visible to:
Edgar Vonk
Sprint: Basel 20
Story Points: 8

 Description   

If ACL for any DAM asset directory (or root) is set do Deny (for any role) assets should not be accessible from front-end website, but those ACL's are not respected in JcrAssetProvider class. This cause situation, when we can not restrict DAM content based on role.



 Comments   
Comment by Sang Ngo Huu [ 11/Nov/15 ]

Hi Mariusz,

There are the reproduce steps below, I guess that I missed somethings during the reproduce steps below:

  • Create role test with:
    read on website with path /, subnodes
    deny on dam with path /, selected node and subnodes
  • Create test user and assign the role above

Observe in front-end, the permission works fine, all links from dam are restricted

Could you please give me more detail about your case?

Comment by Mariusz Chruscielewski [ 12/Nov/15 ]

Hi

It's weird to me as well, but now I checked my test case and it also seems to work. I'm not really sure what has changed since I reported issue, maybe it has something to do with migration from 5.3.10 to 5.4.2 and underlying mechanisms.

No issue then.
Thanks
Mariusz

Generated at Mon Feb 12 05:01:32 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.