overheadhunter
commented
1 year ago calls to unlock(), getDevicesRequiring...(), grantAccess(), addUser(), addGroup(), removeUser() and removeGroup() are blocked and return 403
blocking unlock() should be blocked. But the other calls are technically not harmful in any way. Thus, I would argue that no backend-side check is required. It only adds complexity to the service impl.
update() response depends on the archive status: if the requested vault is archived, it can only be reactivated. If request also wants to update description or name a 403 is returned if the reqested vault is not archived, the name, description and archive status can be updated in one request
Again: This distinction is not required in the service impl.
Let the frontend decide whether it displays certain buttons depending on the archived flag, but technically allow state changes to the vault in the backend. Just make sure any unlock-related stuff and seat counting works as you suggested.
infeo
tobihagemann
Closes #112.
This PR adds the funtionality to archive a vault.
Additionally, the REST endpoint for achieving it let the user also update the vault name and description.The vault is not deleted, it is only marked as archived in the database. The list of members is kept.To implement functionality the the
/vaults/{vaultid}was refactored. It now accepts PUT requests for already existing vaults, but then selectively updates it. Updatable are name, description and archive state.For archived vaults in the backend the following rules hold:
getAccessible()getAllVaults()andgetSomeVaults()unlock()are blocked and return 403As noted by @stefan-karg, users in archived vaults do not increase the license seats. Since the member lists are retained, reactivating a vault can impact the license up to the point that any unlock-operation is blocked because the license limit is exceeded.
A database migration is required which updates the vault table by a new column and filters archived vaults from the effective_vault_access table.
TODOS: