[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?
Thanks.

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.
Regards,
Jan

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.

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