[MAGNOLIA-1293] Role ACL is ignored on public instance Created: 04/Jan/07  Updated: 23/Jan/13  Resolved: 19/Apr/07

Status: Closed
Project: Magnolia
Component/s: core
Affects Version/s: 3.0.1
Fix Version/s: 3.1 M1

Type: Bug Priority: Major
Reporter: Robert Gacki Assignee: Sameer Charles
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

+ JDK 5.0_10
+ Tomcat 5.5.20
+ Magnolia deployed using the WAR-files (magnoliaAuthor.war, magnoliaPublic.war) as they are packaged with this version


Issue Links:
dependency
depends upon MAGNOLIA-1292 "anonymous" user is not logged in by ... Closed
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   

Prerequisites:
+ Create two pages '/one' and '/two'
+ Create a new role 'foo'
+ Assign the ACL entry "deny access' for '/two' (website) on the 'anonymous' user
+ Assign the ACL entry "read only' for '/two' (website) on the 'foo' user
+ Create a new user 'bar' and assign 'foo'
+ Open the pages in the public instance

Bug:
ACLs are ignored. Anonymous users (see MAGNOLIA-1292) can access page '/two' and its contents (which is not really bad). But if you check for READ-permission on the Content instance for '/two' when logged as anonymous TRUE is returned. Based on the ACL entry FALSE is required here. Vice versa, logging in as 'foo' to sea '/two's contents is not necessary.

My proposal:
It is up to the developer / developers business logic to decide, whether to display contents secured by the Magnolia ACLs. ACLs must be respected by the AccessManager on the public instance.



 Comments   
Comment by Sameer Charles [ 04/Jan/07 ]

when you said "anonymous" user is not logged in by default on public instance in report MAGNOLIA-1292
you cannot expect to have any difference whatever role you assign to this user.

once MAGNOLIA-1292 is fixed you should have proper control on public instance.

Comment by Magnolia International [ 04/Jan/07 ]

reopening, since its not really "resolved" yet the two issues are now linked in jira, so we won't forget they're dependent.

Comment by Robert Gacki [ 04/Jan/07 ]

Yes, JIRA does all that.

Meanwhile, I tested another situation. I simply created a new user and assigned the 'anonymous' role to this one. If it is just a dependency (and solved by the root issue), Content#isGranted( Permission.READ ) should have returned FALSE for page '/two' now, but it does not.

No offence Sameer, but this looks much more than a dependency to me. If I can spend some time on it in my weekend, I'll dig into it, too.

Comment by Sameer Charles [ 04/Jan/07 ]

ok my mistake, I should have linked this task!!

Now, what you are saying means that none of the access control works, anonymous user / role is no exception
I tested again and if you login properly and use current user context you wont have any problems.

perhaps you are using wrong context to obtain content objects.

Comment by Robert Gacki [ 04/Jan/07 ]

In the jsp fragment, which creates my navigation I do:

Content activePage = Resource.getCurrentActivePage( (HttpServletRequest) pageContext.getRequest() );
Content rootPage = activePage.getAncestor( 1 ); // Level 2 is '/de/index'
...

Then I use the rootPage to iterate on the branches (rootPage.getChildren()). Each child is checked for read permission:

if( !child.isGranted( info.magnolia.cms.security.Permission.READ ) )
{
continue;
}

Am I wrong with this?

I learned from the taglibs how to access content in a programmatic way.

Generated at Mon Feb 12 03:25:31 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.