bug #7531
closedPermissionDeniedException on flushing registration with modified status even if the user has the required authority
50%
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