Add create-vaults role
#296
Conversation
* `PUT /api/vaults/{vaultId}`
* `POST /api/vaults/{vaultId}/claim-ownership`
* `/app/vaults/create` * `/app/vaults/recover`
[ci skip]
WalkthroughThe changes in this pull request introduce a new role, Changes
Assessment against linked issues
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 4
🧹 Outside diff range and nitpick comments (11)
frontend/src/components/Forbidden.vue (1)
2-16: Styling and responsiveness look good, with a minor suggestion.The use of Tailwind CSS classes for styling and responsiveness is well-implemented. The component adapts to different screen sizes, and the color scheme aligns with the application's primary color.
Consider adding a
transitionclass to the button for a smoother hover effect:- <router-link to="/app/vaults" class="inline-flex items-center px-4 py-2 border border-transparent text-sm font-medium rounded-md shadow-sm text-white bg-primary focus:outline-none focus:ring-2 focus:ring-offset-2 focus:ring-primary"> + <router-link to="/app/vaults" class="inline-flex items-center px-4 py-2 border border-transparent text-sm font-medium rounded-md shadow-sm text-white bg-primary focus:outline-none focus:ring-2 focus:ring-offset-2 focus:ring-primary transition hover:bg-primary-dark">CHANGELOG.md (1)
15-15: LGTM! Consider adding a brief impact statement.The added changelog entry accurately reflects the new feature introduced by this PR, aligning well with the objectives stated in issue #206. The wording is clear and concise, and the placement is appropriate.
To enhance clarity for users reading the changelog, consider adding a brief statement about the impact of this change. For example:
- Permission to create new vaults can now be controlled via the `create-vaults` role in Keycloak (#206) + Permission to create new vaults can now be controlled via the `create-vaults` role in Keycloak, allowing for finer-grained access control (#206)This addition would provide users with a clearer understanding of the feature's significance without significantly increasing the entry's length.
frontend/src/common/auth.ts (1)
Line range hint
1-50: Overall assessment of changes in auth.tsThe changes in this file effectively support the PR objective of introducing a new
create-vaultsrole by replacing specific role-checking methods with a more flexiblehasRolemethod. This modification allows for easier management of various roles, including the newcreate-vaultsrole.Key points:
- The new
hasRolemethod is more versatile than the previousisAdminandisUsermethods.- The implementation uses modern JavaScript features for safer property access.
- The overall structure of the
Authclass remains intact, maintaining consistency with the rest of the codebase.While the changes are generally good, consider implementing the suggested improvements to the
hasRolemethod for increased robustness and type safety.As the application evolves to include more roles and permissions:
- Consider implementing a more comprehensive role management system, possibly using a separate service or utility for role-based access control (RBAC).
- Document the available roles and their meanings in a central location for easier maintenance and onboarding of new developers.
- Implement unit tests for the
Authclass, especially the newhasRolemethod, to ensure correct behavior across different scenarios.frontend/src/components/NavigationBar.vue (1)
Line range hint
1-116: Consider broader implications of role-based access control implementation.The change to use
hasRole('admin')instead ofisAdmin()is a good step towards implementing a more flexible role-based access control system. However, to ensure consistency and proper implementation across the entire application, consider the following:
- Review other components and services that may be using
isAdmin()and update them to use the newhasRolemethod.- Ensure that the 'admin' role encompasses all the permissions that were previously granted by the
isAdmincheck.- Update documentation to reflect this change in the authentication and authorization system.
- Consider adding unit tests to verify the correct behavior of the
hasRolemethod with different user roles.Would you like assistance in identifying other areas of the codebase that might need similar updates?
backend/src/main/resources/dev-realm.json (1)
Line range hint
1-265: Consider adding "create-vaults" to scopeMappingsThe changes implement the required role-based access control for vault creation and correctly assign permissions to Admin, Alice, and Bob. However, I noticed that the "create-vaults" role is not included in the "scopeMappings" section for the "cryptomatorhub" client. This might affect the frontend's ability to determine if a user has vault creation permissions.
Consider adding "create-vaults" to the "scopeMappings" section to ensure proper role mapping in the frontend. Here's a suggested change:
"scopeMappings": [ { "client": "cryptomatorhub", "roles": [ "user", "admin", + "create-vaults" ] } ],This addition would ensure that the "create-vaults" role is properly mapped and accessible in the frontend application.
backend/src/test/java/org/cryptomator/hub/api/VaultResourceIT.java (1)
255-266: LGTM: New test case for role-based access controlThis new test case effectively validates the enforcement of the "create-vaults" role, ensuring that users without this role cannot create vaults. It's a valuable addition to the test suite and aligns well with the PR objectives.
However, there's a minor typo in the method name that should be corrected:
- public void testCreteVaultWithMissingRole() { + public void testCreateVaultWithMissingRole() {frontend/src/router/index.ts (1)
1-1: Remove unnecessary import and update toNavigationGuardSince the
checkRolefunction returnsNavigationGuard, you should importNavigationGuardinstead ofNavigationGuardWithThis. This cleans up the import statement and ensures type consistency.Apply this diff to update the import:
-import { createRouter, createWebHistory, NavigationGuardWithThis, RouteLocationRaw, RouteRecordRaw } from 'vue-router'; +import { createRouter, createWebHistory, NavigationGuard, RouteLocationRaw, RouteRecordRaw } from 'vue-router';frontend/src/components/VaultDetails.vue (4)
Line range hint
153-162: Remove redundant type check forAuthorityDtoinaddAuthorityfunctionSince the
authorityparameter is already typed asAuthorityDto, the type checkif (!isAuthorityDto(authority))is redundant and can be removed to simplify the code.
Line range hint
368-377: Add default case to switch statement inupdateMemberRoleIn the
updateMemberRolefunction, consider adding adefaultcase to theswitchstatement to handle unexpectedmember.typevalues. This enhances robustness and ensures that any unforeseen types are appropriately handled.
Line range hint
290-299: Add default case to switch statement inaddAuthorityBackendIn the
addAuthorityBackendfunction, consider including adefaultcase in theswitchstatement to handle unexpectedauthority.typevalues, which can prevent potential errors due to unhandled types.
Line range hint
215-218: Add error handling inloadVaultKeysfunctionConsider wrapping the code in
loadVaultKeyswithin atry-catchblock to handle potential errors fromdecryptUserKeysWithBrowser()anddecryptWithUserKey(). This will improve error resilience and provide a better user experience if decryption fails.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (10)
- CHANGELOG.md (1 hunks)
- backend/src/main/java/org/cryptomator/hub/api/VaultResource.java (2 hunks)
- backend/src/main/resources/dev-realm.json (3 hunks)
- backend/src/test/java/org/cryptomator/hub/api/VaultResourceIT.java (4 hunks)
- frontend/src/common/auth.ts (1 hunks)
- frontend/src/components/Forbidden.vue (1 hunks)
- frontend/src/components/NavigationBar.vue (1 hunks)
- frontend/src/components/VaultDetails.vue (1 hunks)
- frontend/src/components/VaultList.vue (3 hunks)
- frontend/src/router/index.ts (5 hunks)
🧰 Additional context used
🔇 Additional comments (21)
frontend/src/components/Forbidden.vue (2)
1-17: LGTM: Well-structured and informative error page.The template provides a clear and informative "403 Forbidden" error page. The structure is well-organized, displaying the error code, a heading, and a descriptive message. The layout appears to be responsive, adapting to different screen sizes through the use of Tailwind CSS classes.
5-13: Enhance accessibility and verify router link.The error message is clearly conveyed through text, which is good for screen readers. The router link provides a clear navigation option.
Consider these accessibility enhancements:
- Add an
aria-labelto the error code for better screen reader context:- <p class="text-4xl font-extrabold text-primary sm:text-5xl">403</p> + <p class="text-4xl font-extrabold text-primary sm:text-5xl" aria-label="Error code 403">403</p>- Use a more semantic
<h2>tag for the "Forbidden" text:- <h1 class="text-4xl font-extrabold text-gray-900 tracking-tight sm:text-5xl">Forbidden</h1> + <h2 class="text-4xl font-extrabold text-gray-900 tracking-tight sm:text-5xl">Forbidden</h2>Verify the router link functionality with this script:
CHANGELOG.md (1)
Line range hint
1-41: Overall changelog structure and content look great!The changelog is well-structured and comprehensive, following the Keep a Changelog format. It effectively captures all the major changes, including the new
create-vaultsrole, dependency updates, and security fixes. The categorization of changes into Added, Changed, Fixed, and Security sections provides clear organization and makes it easy for users to understand the nature of each update.frontend/src/common/auth.ts (1)
48-50: Approve changes with suggestions for improvementsThe new
hasRolemethod is a good addition that provides more flexibility in role checking. It aligns well with the PR objective of introducing a newcreate-vaultsrole. However, there are a couple of suggestions for improvement:
- Consider adding a type check for the
roleparameter to ensure it's a non-empty string.- The method could be more robust by also checking for roles directly on
tokenParsedifrealm_accessis undefined.Here's a suggested implementation that addresses these points:
public hasRole(role: string): boolean { if (typeof role !== 'string' || role.length === 0) { throw new Error('Role must be a non-empty string'); } return ( this.keycloak.tokenParsed?.realm_access?.roles?.includes(role) ?? this.keycloak.tokenParsed?.roles?.includes(role) ?? false ); }This implementation:
- Adds a type check for the
roleparameter.- Checks for roles in both
realm_access.rolesand directly inrolesontokenParsed.- Maintains the use of optional chaining and nullish coalescing for safe access.
To ensure that this change doesn't break existing functionality, please run the following script to check for any remaining usage of the removed
isAdminandisUsermethods:If any occurrences are found, they should be updated to use the new
hasRolemethod.✅ Verification successful
Verified: No remaining usages of
isAdmin()orisUser()methods found in the./frontenddirectory.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for any remaining usage of removed methods # Test: Search for isAdmin() and isUser() method calls echo "Searching for isAdmin() method calls:" rg --type typescript "\.isAdmin\(\)" ./frontend echo "Searching for isUser() method calls:" rg --type typescript "\.isUser\(\)" ./frontendLength of output: 336
Script:
#!/bin/bash # Description: Check for any remaining usage of removed methods with correct file types # Test: Search for isAdmin() and isUser() method calls in TypeScript files echo "Searching for isAdmin() method calls:" rg --type ts "\.isAdmin\(\)" ./frontend echo "Searching for isUser() method calls:" rg --type ts "\.isUser\(\)" ./frontend # Additionally, search in .tsx files if present echo "Searching for isAdmin() method calls in .tsx files:" rg --type tsx "\.isAdmin\(\)" ./frontend echo "Searching for isUser() method calls in .tsx files:" rg --type tsx "\.isUser\(\)" ./frontendLength of output: 615
Script:
#!/bin/bash # Description: Check for any remaining usage of removed methods using file extension patterns # Test: Search for isAdmin() and isUser() method calls in .ts and .tsx files echo "Searching for isAdmin() method calls in .ts and .tsx files:" rg "\.isAdmin\(\)" ./frontend -g "*.ts" -g "*.tsx" echo "Searching for isUser() method calls in .ts and .tsx files:" rg "\.isUser\(\)" ./frontend -g "*.ts" -g "*.tsx"Length of output: 360
frontend/src/components/NavigationBar.vue (1)
110-110: LGTM! Verify 'admin' role setup andhasRoleimplementation.The change from
isAdmin()tohasRole('admin')aligns well with the PR objectives of implementing a role-based permission system. This approach is more flexible and consistent with RBAC best practices.To ensure this change works as intended, please verify:
- The 'admin' role is correctly set up in the backend.
- The
hasRolemethod in theauthobject is implemented correctly.Run the following script to check the implementation of the
hasRolemethod:backend/src/main/resources/dev-realm.json (4)
19-23: LGTM: New role "create-vaults" correctly definedThe new "create-vaults" role is well-defined with an appropriate name, description, and composite flag. This addition aligns with the PR objectives to introduce a role for managing vault creation permissions.
30-31: LGTM: "admin" role correctly updated with "create-vaults" compositeThe "admin" role has been appropriately updated to include the "create-vaults" role in its composites. This change ensures that administrators have the necessary permissions to create vaults, which is consistent with the PR objectives.
82-82: LGTM: Alice's realm roles correctly updatedAlice's realm roles have been appropriately updated to include both "user" and "create-vaults". This change aligns with the PR objectives, granting Alice the permission to create vaults while maintaining her basic user permissions.
91-91: LGTM: Bob's realm roles correctly updatedBob's realm roles have been appropriately updated to include both "user" and "create-vaults". This change aligns with the PR objectives, granting Bob the permission to create vaults while maintaining his basic user permissions.
backend/src/test/java/org/cryptomator/hub/api/VaultResourceIT.java (5)
248-248: LGTM: Updated role in @testsecurity annotationThe change from
roles = {"user"}toroles = {"create-vaults"}aligns with the PR objective of introducing a new "create-vaults" role. This ensures that the tests in this class are run with the appropriate permissions, accurately reflecting the new role-based access control for vault creation.
663-663: LGTM: Updated roles in @testsecurity annotationThe change to include both
"user"and"create-vaults"roles in the@TestSecurityannotation is appropriate. This ensures that the tests in this class are run with both standard user permissions and the new vault creation permissions, accurately reflecting the intended role-based access control. This change is consistent with the PR objective of introducing the new "create-vaults" role while maintaining existing functionality.
1010-1025: LGTM: New test case for role-based access control on claim ownershipThis new test case effectively validates the enforcement of the "create-vaults" role for the claim ownership functionality. It ensures that users without this role cannot claim ownership of vaults, which is consistent with the PR objectives. The test is well-structured and provides good coverage for the new role-based access control implementation.
Line range hint
1-1170: Summary: Comprehensive implementation and testing of the new "create-vaults" roleThe changes in this file consistently implement and test the new "create-vaults" role across different functionalities of the VaultResource. Key points:
- Test security annotations have been updated to include the new role where appropriate.
- New test cases have been added to validate the role-based access control for vault creation and ownership claiming.
- Existing test classes have had their roles updated to include or focus on the "create-vaults" role.
These changes align well with the PR objectives of introducing a new role for vault creation. The test coverage for the new role seems comprehensive, and there's a good balance between testing the new functionality and ensuring existing functionality is not broken.
Overall, these changes provide a solid foundation for the new role-based access control system for vault creation and management.
848-848: LGTM with a question: Updated role in @testsecurity annotationThe change to include only the
"create-vaults"role in the@TestSecurityannotation aligns with the PR objective of introducing the new role for vault creation. However, I have a question:Does removing the "user" role impact any tests in this class that might rely on standard user permissions? If not, this change is appropriate. If there are tests that require standard user permissions, we might need to keep both roles or split the test class.
To verify if any tests in this class require standard user permissions, we can run the following script:
✅ Verification successful
To further assess the impact of removing the
"user"role from the@TestSecurityannotation inVaultResourceIT.java, let's identify all instances where the"user"role is used.
Verified: Removal of "user" role does not impact other tests
The removal of the
"user"role from the@TestSecurityannotation inVaultResourceIT.java(lines 848-848) is appropriate. Other tests within the class continue to utilize the"user"role where necessary, ensuring that standard user permissions remain intact.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for method calls or assertions that might rely on standard user permissions rg -i 'user|permission|access' backend/src/test/java/org/cryptomator/hub/api/VaultResourceIT.javaLength of output: 16557
Script:
#!/bin/bash # List all @TestSecurity annotations with the "user" role in VaultResourceIT.java rg '@TestSecurity.*\{"user"\}' backend/src/test/java/org/cryptomator/hub/api/VaultResourceIT.javaLength of output: 654
frontend/src/router/index.ts (4)
67-68: Usage ofcheckRole('create-vaults')is appropriateThe role check for
'create-vaults'is correctly applied to the vault creation route. This ensures that only authorized users can access the vault creation page.
73-74: Role check for vault recovery is correctly implementedThe
beforeEnterguard correctly checks for the'create-vaults'role on the vault recovery route. This maintains consistent access control for vault-related actions.
87-87: Admin route role check is appropriately updatedThe
beforeEnterguard now usescheckRole('admin'), streamlining the role-checking logic for admin routes. This enhances code maintainability and readability.
128-132: Forbidden route is correctly definedThe
/app/forbiddenroute is added appropriately to handle unauthorized access. Settingmeta: { skipAuth: true, skipSetup: true }ensures that users are redirected here without additional authentication or setup checks.backend/src/main/java/org/cryptomator/hub/api/VaultResource.java (2)
391-391: Verify role assignment forcreateOrUpdatemethodThe
@RolesAllowed("create-vaults")annotation restricts access to users with thecreate-vaultsrole for thecreateOrUpdatemethod. Please ensure that all users who need to create or update vaults are assigned this role in Keycloak, and that this aligns with the intended permission model.
442-442: Confirm role restriction forclaimOwnershipmethodThe
@RolesAllowed("create-vaults")annotation now restricts theclaimOwnershipmethod to users with thecreate-vaultsrole. Verify that this change correctly reflects the desired access control and that users who need to claim ownership have the appropriate role.frontend/src/components/VaultDetails.vue (1)
286-286: Change to usehasRole('admin')for admin status check is appropriateThe update from
isAdmintohasRole('admin')correctly determines admin privileges based on roles. This change aligns with the introduction of thecreate-vaultsrole and enhances role-based access control within the component.
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Outside diff range and nitpick comments (1)
frontend/src/router/index.ts (1)
129-133: LGTM with a minor suggestion: /app/forbidden routeThe addition of the /app/forbidden route is a necessary component of the role-based access control system. The use of the Forbidden component and the meta settings are appropriate.
Consider adding a name to this route for easier reference in navigation guards:
{ path: '/app/forbidden', name: 'forbidden', component: Forbidden, meta: { skipAuth: true, skipSetup: true } },This named route can then be used in navigation guards like this:
return { name: 'forbidden', replace: true };Would you like me to provide a code snippet for this change?
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (2)
- frontend/src/components/VaultList.vue (3 hunks)
- frontend/src/router/index.ts (5 hunks)
🧰 Additional context used
🔇 Additional comments (7)
frontend/src/router/index.ts (4)
17-17: LGTM: Import of Forbidden componentThe addition of the Forbidden component import is consistent with the implementation of role-based access control, as outlined in the PR objectives.
68-69: LGTM: Role-based access control for vault creationThe changes to the vaults/create route correctly implement the role-based access control for vault creation, as specified in the PR objectives. The use of a props function to set
recover: falseis a good practice for passing data to components.
74-75: LGTM: Consistent role-based access control for vault recoveryThe changes to the vaults/recover route are consistent with those made to the vaults/create route, correctly implementing role-based access control for vault recovery. This aligns with the PR objectives and maintains consistency across related routes.
Line range hint
1-233: Summary: Successful implementation of role-based access controlThe changes in this file successfully implement the role-based access control for vault creation and recovery, as specified in the PR objectives. The new
checkRolefunction provides a centralized mechanism for role verification, and the route updates consistently apply this check where needed.Key points:
- The
checkRolefunction implementation is solid, with minor suggestions for improvement in type safety and logging.- Route guards for vault creation and recovery have been updated consistently.
- A new '/app/forbidden' route has been added to handle unauthorized access attempts.
Overall, the changes are well-implemented and align closely with the PR objectives. The suggested improvements are minor and do not impact the core functionality.
frontend/src/components/VaultList.vue (3)
43-43: Changes look good for disabling the MenuButtonThe
MenuButtonnow correctly disables the ability to create vaults when the license is violated or the user lacks thecreate-vaultsrole.
150-151: Proper initialization of reactive propertiesInitializing
isAdminandcanCreateVaultstofalseprevents undefined behavior before the asynchronous assignment completes infetchData().
181-182: Optimize role checks by minimizing redundant await callsAs previously suggested, you can await
authonce and then perform all role checks to improve performance.
This PR fixes #206 by introducing the
create-vaultsrole.Note that the
dev-realmadds this role only for usersadmin,aliceandbob, while the userscarol,daveanderinare not allowed to create vaults.