[MAGNOLIA-3915] URI Permission assignment does not respect multi-site configuration Created: 08/Sep/11  Updated: 12/Sep/12  Resolved: 13/Jan/12

Status: Closed
Project: Magnolia
Component/s: None
Affects Version/s: 4.4.2
Fix Version/s: 4.4.6

Type: Bug Priority: Neutral
Reporter: Vit Kroutil Assignee: Ondrej Chytil
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
causality
is causing MGNLETK-72 Admincentral website trees take a lon... Closed
dependency
depends upon MGNLETK-66 URI Permission assignment does not re... Closed
relation
is related to MGNLSTK-822 AggregationState improvements for sit... Closed
is related to MAGNOLIA-3914 Site aware ACL - port Closed
is related to MGNLEE-215 Content from one site is also availab... Closed
is related to MAGNOLIA-4526 Disable site-aware ACL check for auth... 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   

URISecurityFilter only takes into account the path section of a URL when evaluating permissions



 Comments   
Comment by Ondrej Chytil [ 07/Dec/11 ]

Solved by allowing site-aware acl paths - <siteName>path_as_was_before. For proper functionality of this multisite filter has to be moved before uriSecurity - MGNLETK-66. Test case added also under MGNLETK-66.

Comment by Ondrej Chytil [ 13/Dec/11 ]

Port ticket - SCRUM-713.

Comment by Daniel Lipp [ 14/Dec/11 ]

Looks like there's no obvious way to avoid the workaround in 4.4. For 4.5 there's the new ticket so that's looks fine.

Only thing that should be changed is the unnecessary catch of the SecurityException and the re-throwing of the InvokationTargetException.

So my proposal for the workaround is:

        //workaround to call ExtendedAggregationState methods
        Method getSite;
        try {
            getSite = aggregationState.getClass().getMethod("getSite");
            Object sitePOJO = getSite.invoke(aggregationState);
            String siteName = (String) sitePOJO.getClass().getMethod("getName").invoke(sitePOJO);
            return site.equals(siteName);
        } catch (NoSuchMethodException e) {
            log.debug("Not proper ExtendedAggregationState provided");
        } catch (IllegalArgumentException e) {
            log.debug("Not proper ExtendedAggregationState provided");
        } catch (IllegalAccessException e) {
            log.debug("Not proper ExtendedAggregationState provided");
        } catch (InvocationTargetException e) {
            log.debug("Not proper ExtendedAggregationState provided");
        }
        return false;

In addition there should be a test for that new method.

Comment by Jan Haderka [ 23/Dec/11 ]

Junit test?

Comment by Ondrej Chytil [ 27/Dec/11 ]

Test commited under MGNLETK-66 as said in my resolve comment.

Comment by Daniel Lipp [ 27/Dec/11 ]

Pls add test covering new behavior of SimpleUrlPattern

Comment by Daniel Lipp [ 27/Dec/11 ]

After double checking we found that testing new behavior in SimpleUrlPatternTest would be too big effort - SimpleUrlPattern is "using" ExtendedAggregation state although it's located in core. As there's already tests for it in EtkSiteManager (introduced with MGNLETK-66) and as the problem will be solved differently in trunk, it's fine as it is...

Comment by Ondrej Chytil [ 03/Jan/12 ]

Due to some troubles caused by moving multisite filter there are few improvements needed.

Comment by Boris Kraft [ 05/Jan/12 ]

Ondrej, this comment would be more useful if you explain what troubles and what improvements you think of

Comment by Ondrej Chytil [ 10/Jan/12 ]

Re-fixed because Multisite filter current URI shortening caused troubles in pattern handling.
Also site which was get for comparison was based on content, now it's get just by domain name as parameter. Both was solved by MGNLSTK-822.

Despite the fact this was re-written site-aware ACLs work as described before: <siteName>/path/to_something.

Comment by Milan Divilek [ 12/Jan/12 ]

solution of this issue has side affect to data permission
AccessDeniedException: User not allowed to Read path [/contacts/JMustermann]

Comment by Ondrej Chytil [ 12/Jan/12 ]

Still some cases not covered.

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