[MAGNOLIA-1645] Renaming the secured page (in anonymours role's URL acl) does not update URL acl definition Created: 27/Jul/07 Updated: 01/Sep/10 Resolved: 01/Sep/10 |
|
| Status: | Closed |
| Project: | Magnolia |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | zam6ak | Assignee: | Boris Kraft |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
3.1-SNAPSHOT |
||
| 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 |
|
Scenation: 1. create a page called pageA and publish on public instance pageB is unsecured because anonymous role URL acl didn't "update" page name. It stayed pageA. (i think its because it is not ussing UUID internally but just a string) Potential side effects can be very serious for public sites. Workaround:
|
| Comments |
| Comment by Boris Kraft [ 27/Jul/07 ] |
|
I am not sure this can be considered a bug. It depends on how you look at it. If you consider the secureURI and the actual pages as independent, then it is a feature that should be the way it is now. If on the other hand you think they should go together, it would probably be better to secure on the page level (i.e. somehow directly in the site tree or in the page properties) to make it clear that the page is protected, and not a path. |
| Comment by zam6ak [ 27/Jul/07 ] |
|
If you open a role dialog and look at the other workspaces (website, config,etc, etc) they all have "Choose.." button.... Why is this not the case with URL acl? If I rename the page, every aspect of the role configuration gets updated accordingly (reflecting the change) (because internally UUID is being used) while URL acl is not (because I think it is stored as a string). Besides to protect a page you need 2 rules (to accomodate default voter config) and then 1 more to protect subpages consider /some/pageA.html To protect pageA and all subpages one needs Deny access on URL for: Now lets consider security implications. If user protects pageA and then later decides to rename it and create a different page called pageA (in the same level obviously) you end up with intended page not being protected and with new page being protected which is hardly what user expects. Because of inconsistent behaviour in the role definitions (not being tracked by UUID) and because of security implications I opened the issue as a bug. I home my reasoning makes sense. |
| Comment by Sean McMains [ 18/Aug/10 ] |
|
Isn't this just a specific case of the general issue in |
| Comment by Philipp Bärfuss [ 01/Sep/10 ] |
|
Yes, |