-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[AC-1344] Provider users unable to bulk restore vault items for client organizations #2871
[AC-1344] Provider users unable to bulk restore vault items for client organizations #2871
Conversation
…efactored PutRestoreMany
…ore-vault-items-for-client-organizations
…ore-vault-items-for-client-organizations # Conflicts: # src/Sql/Sql.sqlproj
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think having -admin
variants of basic operations is an antipattern. It duplicates a lot of the logic - the request, the controller endpoint, conditional logic in the service, and the db sproc, all to do the same thing (restore some ciphers). The only difference is the user's role, which is just authorization logic.
Can you please consider whether we can
- create a
CiphersAuthorizationHandler
to encapsulate authorization logic (refer back to [AC-1387] Resource-based authentication for Groups #2845 for this pattern) - have 1 repository method + sproc which just restores the provided
cipherIds
, without needing to distinguish between users and admins
So the flow could more or less be
- get ciphers (or
CipherDetails
, whatever the auth logic requires) - pass them to
bitAuthorizationService
to check permissions - restore ciphers
- log the events
(That's very simplified - it may not be that tidy - but that's the ideal.)
This also has the advantage of creating up CiphersAuthorizationHandler
for future use. If we can't do the full refactor above then I'd at least like to do that.
…ore-vault-items-for-client-organizations
…ore-vault-items-for-client-organizations
…ore-vault-items-for-client-organizations
No New Or Fixed Issues Found |
@eliykat as we've agreed to refactor this later to use resource-based authentication, please re-review this. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good! I'll also request a review from the Vault Team because ciphers are their domain.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would be good to add a test for the new parameters/behaviour as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Test added!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Everything looks good. I just have asked one question.
This looks good. Nice job! |
Type of change
Objective
Bulk restoring items in the web vault is not working for Provider users because the existing API endpoint only allows that action for Organization members.
Code changes
This PR is related to this clients PR.
ListResponseModel<CipherMiniResponseModel>
and moved logic toCipherService
. Added new endpointPutRestoreManyAdmin
OrganizationId
field toCipherBulkRestoreRequestModel
RestoreByIdsOrganizationIdAsync
to restore certain ciphers for an organizationorganizationId
andorgAdmin
toRestoreManyAsync
and updated output toICollection<CipherOrganizationDetails>
organizationId
value is passed andorgAdmin == true
thenCipherRepository.RestoreByIdsOrganizationIdAsync
is used otherwise itsCipherRepository.RestoreAsync
Cipher_RestoreByIdsOrganizationId.sql
Before you submit
dotnet format --verify-no-changes
) (required)