[MAGNOLIA-1993] Inconsistent security checks on activation/deactivation Created: 09/Jan/08  Updated: 23/Jan/13  Resolved: 24/Jan/08

Status: Closed
Project: Magnolia
Component/s: activation
Affects Version/s: 3.5 RC1, 3.5 RC2, 3.5 RC3, 3.5, 3.5.1, 3.5.2
Fix Version/s: 3.5.4

Type: Bug Priority: Critical
Reporter: Jan Haderka Assignee: Philipp Bärfuss
Resolution: Not an issue Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

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   

After fixing MAGNOLIA-1536 security checks performed on activation/deactivation are now inconsistent. To activate the document permission to access /ActivationHandler is satisfactory condition (no write permission to the given part of repository necessary), however to deactivate document user needs to be able to access the /ActivationHandler and needs REMOVE permission on deactivated document. This leads to situation where user can activate the document but has no permission to deactivate it.



 Comments   
Comment by Yuanhua Qu [ 23/Jan/08 ]

Version magnolia 3.5.3

A user can activate a page even if that user is not activated or role assigned to that user is not activated. In early version 3.0.5, a user can only activate a page when that user and role assigned to that user is activated.

If user and role assigned are both not activated, that user can still try deactivate that page without any error alert and status shows deactivated although in fact that page was not deactivated at all. If user or role, one of them is activated, user tries to deactivate the page, alert message appears but status still shows deactivated in author instance although it was not deactivated at all.

Comment by Philipp Bracher [ 24/Jan/08 ]

I will investigate on that. Actually /ActivationHandler is not protected. The user permissions must be taken in account!

Comment by Philipp Bracher [ 24/Jan/08 ]

The content security (ACLs) is considered. So there is no security issue with that.

I am going to create a new issue for moving /ActivationHandler to /.magnolia/ActivationHandler or similar to make the url protection more consistent

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