Project

General

Profile

Actions

bug #7531

closed

PermissionDeniedException on flushing registration with modified status even if the user has the required authority

Added by Andreas Kohlbecker almost 6 years ago. Updated over 5 years ago.

Status:
Closed
Priority:
Highest
Category:
cdmlib
Target version:
Start date:
Due date:
% Done:

50%

Estimated time:
Severity:
critical
Found in Version:

Description

User with the Grantedauthority REGISTRATION(PREPARATION).[UPDATE]{06649467-7c4f-4b8b-98e6-395e4d3af240} changes the status of the Registration (uuid=06649467-7c4f-4b8b-98e6-395e4d3af240) from PREPARATION to CURATION. Saving the moidifcation to the storage fails with a PermissionDeniedException.

This happens because the RegistrationVoter only sees the updates RegistrationStatus not the old one.

Potential solution:

1)

The parameters Object[] previousState, String[] propertyNames available in the interceptor methods (CdmSecurityHibernateInterceptor) these must also be passed to PermissionVoters in general, particularity to the furtherVotingDecission() method.

  • This makes the authorization implementation more complex but would also offer more degrees of freedom.

2)

The Submitter is granted with REGISTRATION(PREPARATION,CURATION).[UPDATE]{06649467-7c4f-4b8b-98e6-395e4d3af240}.

  • The Submitter would be enabled to save the state transition PREPARATION -> CURATION.
  • Drawback: But this brings the drawback that the user would be able to modify the registration when it passed to the curation, be e.g adding typeDesignations. This problem could be avoided by revoking this permission when the status changes by e.g. the GrantedAuthorityRevokingRegistrationUpdateLister (see #7148)

3)

The Submitter is granted with REGISTRATION.[UPDATE]{06649467-7c4f-4b8b-98e6-395e4d3af240}.

  • Drawback: But this brings the drawback that the user would be able to modifiy registrations in any status This problem must be reliably avoided by revoking this permission when the status changes by e.g. the GrantedAuthorityRevokingRegistrationUpdateLister (see #7148)

4)

The RegistrationStatus change is performed by special service bean which does it on behalf of the user. The submitter would trigger sending a event to this service bean to request for the status change. The service bean in turn checks the permissions of the requester and would then execute the status change in a runAs environment as SYSTEM_USER.

  • Drawback: The updated by would not mention the submitter.

Related issues

Related to EDIT - bug #7528: Allow changing the Registration status in the RegistrationWorkingsetEditorClosedAndreas Kohlbecker

Actions
Related to EDIT - feature request #7148: GrantedAuthorityRevokingRegistrationUpdateLister: delete orphan references to GrantedAuthorityImpl in User and GroupClosedAndreas Kohlbecker

Actions
Actions

Also available in: Atom PDF