[DOCU-329] On public instance: cache images can not be created by anonymous (ACL not considered) Created: 12/Oct/12 Updated: 22/Sep/15 Resolved: 22/Sep/15 |
|
| Status: | Closed |
| Project: | Documentation |
| Component/s: | content |
| Affects Version/s: | short term |
| Fix Version/s: | short term |
| Type: | Improvement | Priority: | Major |
| Reporter: | Jonas Petersen [X] (Inactive) | Assignee: | Unassigned |
| Resolution: | Obsolete | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
Magnolia 4.5.3, 4.5.5, Tomcat 7.0.29 |
||
| Description |
|
On my public instance there are some images that are not displayed. The images by it self will show a login screen and an Exception is thrown: ERROR info.magnolia.module.cache.filter.CacheFilter : A request started to cache but failed with an exception (AccessDeniedException: Access denied). Some images are displayed though. It turns out that as soon an image is created by a non-anomymous user once, it will be displayed by anonymous users from then on. The anonymous user has of course the appropriate rights (read/write to imaging): Role: imaging-base Read/Write permission in the workspace imaging with path /* (No other rules on workspace imaging.) I debugged it down to the AccessDeniedException that is thrown in SimpleAccessManager when the cache image is tried to be created. org.apache.jackrabbit.core.security.simple.SimpleAccessManager public void checkPermission(Path absPath, int permissions) throws AccessDeniedException, RepositoryException { if (!isGranted(absPath, permissions)) { throw new AccessDeniedException("Access denied"); } } isGranted will end up here: ... } else if (anonymous) { // anonymous is only granted READ permissions return permissions == Permission.READ; } ... (SimpleAccessManager.anoymous is true.) So the ACL is obviously never considered. Am I doing something wrong? Or is this a bug? Tested in 4.5.3 and 4.5.5 |
| Comments |
| Comment by Jan Haderka [ 13/Oct/12 ] |
|
Could you please provide exact instructions on how to reproduce this problem? |
| Comment by Jonas Petersen [X] (Inactive) [ 14/Oct/12 ] |
|
I tried to reproduce it with the demo-project on a fresh install, but it's working as expected there. I found out why though: it's not using SimpleAccessManager but DefaultAccessManager. It turns out that we're sticking with an outdated jackrabbit-bundle-derby-search.xml. This exact file was using SimpleAccessManager until Tue Mar 22 2012. On that day the config changed to DefaultAccessManager (view diff). So this can be closed. (I'm not the first one to stumble over this: forum thread) |
| Comment by Jan Haderka [ 14/Oct/12 ] |
|
Yeah, i wondered how you end up in SimpleAccessManager. Thought that maybe we missed imaging somehow. You are right that more ppl stumble over forgotten update of JR config so rather then closing this issue I moved it to documentation to make sure this exists somewhere as a tip. Thanks for reporting the problem. |
| Comment by Jonas Petersen [X] (Inactive) [ 14/Oct/12 ] |
|
Ok, great. By the way, another effect of this was that it was not possible to restrict access for certain users to the website tree. Every user - no matter what acl they got - could just see the whole tree and also write to the whole tree. |
| Comment by Christoph Meier [ 22/Sep/15 ] |
|
Ticket is old and inactive for a long time. And such issue - if it exists - should be in another JIRA project. |