[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: |
|
||||||||||||||||||||||||||||||||||||
| 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 - |
| Comment by Ondrej Chytil [ 13/Dec/11 ] |
|
Port ticket - |
| 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 |
| 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 |
| 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. 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 |
| Comment by Ondrej Chytil [ 12/Jan/12 ] |
|
Still some cases not covered. |