[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
JBoss 4.0.5


Issue Links:
supersession
is superseded by MAGNOLIA-1542 roles dialog does not resolve the pag... 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   

Scenation:

1. create a page called pageA and publish on public instance
2. on public instance enter URL acl for anonymous role protecting access to the pageA
3. try to access pageA - you will get login prompt
4. on author, rename pageA to pageB and republish
5. try to access pageB and it is unsecured.

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:

  • don't rename pages once secured
  • after renaming pages updated anonymous role URL acl


 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....
When you enter a URL in one of those configurations any page rename is reflected in the role configurations as well...

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:
/some/pageA
/some/pageA.*
/some/pageA/*

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 MAGNOLIA-1542?

Comment by Philipp Bärfuss [ 01/Sep/10 ]

Yes, MAGNOLIA-1542 is the more generic ticket. This issue can be closed.

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