-
-
Notifications
You must be signed in to change notification settings - Fork 9
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
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
📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (1)
🧰 Additional context used🔇 Additional comments (4)
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 (
|
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.
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
transition
class 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-vaults
role by replacing specific role-checking methods with a more flexiblehasRole
method. This modification allows for easier management of various roles, including the newcreate-vaults
role.Key points:
- The new
hasRole
method is more versatile than the previousisAdmin
andisUser
methods.- The implementation uses modern JavaScript features for safer property access.
- The overall structure of the
Auth
class remains intact, maintaining consistency with the rest of the codebase.While the changes are generally good, consider implementing the suggested improvements to the
hasRole
method 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
Auth
class, especially the newhasRole
method, 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 newhasRole
method.- Ensure that the 'admin' role encompasses all the permissions that were previously granted by the
isAdmin
check.- Update documentation to reflect this change in the authentication and authorization system.
- Consider adding unit tests to verify the correct behavior of the
hasRole
method 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 toNavigationGuard
Since the
checkRole
function returnsNavigationGuard
, you should importNavigationGuard
instead 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 forAuthorityDto
inaddAuthority
functionSince the
authority
parameter 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 inupdateMemberRole
In the
updateMemberRole
function, consider adding adefault
case to theswitch
statement to handle unexpectedmember.type
values. This enhances robustness and ensures that any unforeseen types are appropriately handled.
Line range hint
290-299
: Add default case to switch statement inaddAuthorityBackend
In the
addAuthorityBackend
function, consider including adefault
case in theswitch
statement to handle unexpectedauthority.type
values, which can prevent potential errors due to unhandled types.
Line range hint
215-218
: Add error handling inloadVaultKeys
functionConsider wrapping the code in
loadVaultKeys
within atry-catch
block 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-label
to 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-vaults
role, 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
hasRole
method is a good addition that provides more flexibility in role checking. It aligns well with the PR objective of introducing a newcreate-vaults
role. However, there are a couple of suggestions for improvement:
- Consider adding a type check for the
role
parameter to ensure it's a non-empty string.- The method could be more robust by also checking for roles directly on
tokenParsed
ifrealm_access
is 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
role
parameter.- Checks for roles in both
realm_access.roles
and directly inroles
ontokenParsed
.- 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
isAdmin
andisUser
methods:If any occurrences are found, they should be updated to use the new
hasRole
method.✅ Verification successful
Verified: No remaining usages of
isAdmin()
orisUser()
methods found in the./frontend
directory.🏁 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 andhasRole
implementation.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
hasRole
method in theauth
object is implemented correctly.Run the following script to check the implementation of the
hasRole
method: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@TestSecurity
annotation 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@TestSecurity
annotation 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@TestSecurity
annotation 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@TestSecurity
annotation 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
beforeEnter
guard 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
beforeEnter
guard 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/forbidden
route 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 forcreateOrUpdate
methodThe
@RolesAllowed("create-vaults")
annotation restricts access to users with thecreate-vaults
role for thecreateOrUpdate
method. 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 forclaimOwnership
methodThe
@RolesAllowed("create-vaults")
annotation now restricts theclaimOwnership
method to users with thecreate-vaults
role. 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
isAdmin
tohasRole('admin')
correctly determines admin privileges based on roles. This change aligns with the introduction of thecreate-vaults
role and enhances role-based access control within the component.
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.
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: false
is 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
checkRole
function provides a centralized mechanism for role verification, and the route updates consistently apply this check where needed.Key points:
- The
checkRole
function 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
MenuButton
now correctly disables the ability to create vaults when the license is violated or the user lacks thecreate-vaults
role.
150-151
: Proper initialization of reactive propertiesInitializing
isAdmin
andcanCreateVaults
tofalse
prevents undefined behavior before the asynchronous assignment completes infetchData()
.
181-182
: Optimize role checks by minimizing redundant await callsAs previously suggested, you can await
auth
once and then perform all role checks to improve performance.
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.
Will do some testing now, but as initial feedback: Not having the new create-vault
role is the new default, and specifically because of this, we need to change the display text in the vault list for users without the create-vault
role to say that they cannot create vaults because they do not have that role set...to not confuse them too much.
Maybe we should also add this note in a tooltip to the Add
button when disabled, so that even users who are members of another vault know why they cannot create vaults, or should we remove the button altogether?
backend/src/main/java/org/cryptomator/hub/api/VaultResource.java
Outdated
Show resolved
Hide resolved
I decided against removing the button altogether as seeing the button sparks the question why the user can't add a vault (as opposed to where she can do so, if it were completely missing). I believe that when something is not working as expected, a good UI should at least make you ask the right questions. An even better UI even provides the answer and I agree that a tooltip (among others) is a good means. Edit: Added in f9eda5c |
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.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (4)
frontend/src/components/VaultList.vue (2)
43-46
: LGTM! Consider addingaria-label
for improved accessibility.The changes effectively implement role-based access control for vault creation and provide user feedback through the title attribute, aligning with the PR objectives. Great job on addressing the suggestion to add a tooltip!
To further enhance accessibility, consider adding an
aria-label
attribute that matches the title content. This ensures screen readers can convey the button's state and any associated messages.- <MenuButton :disabled="isLicenseViolated || !canCreateVaults" class="inline-flex items-center px-4 py-2 border border-transparent rounded-md shadow-sm text-sm font-medium text-white bg-primary hover:bg-primary-d1 focus:outline-none focus:ring-2 focus:ring-offset-2 focus:ring-primary disabled:cursor-not-allowed disabled:opacity-50" :title="isLicenseViolated ? t('vaultList.addVault.disabled.licenseViolation') : canCreateVaults ? undefined : t('vaultList.addVault.disabled.missingPermission')"> + <MenuButton :disabled="isLicenseViolated || !canCreateVaults" class="inline-flex items-center px-4 py-2 border border-transparent rounded-md shadow-sm text-sm font-medium text-white bg-primary hover:bg-primary-d1 focus:outline-none focus:ring-2 focus:ring-offset-2 focus:ring-primary disabled:cursor-not-allowed disabled:opacity-50" :title="isLicenseViolated ? t('vaultList.addVault.disabled.licenseViolation') : canCreateVaults ? undefined : t('vaultList.addVault.disabled.missingPermission')" :aria-label="isLicenseViolated ? t('vaultList.addVault.disabled.licenseViolation') : canCreateVaults ? t('vaultList.addVault') : t('vaultList.addVault.disabled.missingPermission')">
181-182
: LGTM! Consider optimizing role checks.The implementation of role-based access control for vault creation aligns well with the PR objectives. Good job on using
auth.hasRole()
to check for both admin and create-vaults roles.To optimize performance, consider awaiting
auth
once and then performing both role checks. This addresses a suggestion from a past review comment:- isAdmin.value = (await auth).hasRole('admin'); - canCreateVaults.value = (await auth).hasRole('create-vaults'); + const userAuth = await auth; + isAdmin.value = userAuth.hasRole('admin'); + canCreateVaults.value = userAuth.hasRole('create-vaults');This change reduces the number of async operations and slightly improves the function's performance.
frontend/src/i18n/en-US.json (1)
248-248
: LGTM! Consider adding more detail to the message.The new entry for the license violation scenario is well-placed and follows the existing naming conventions. It provides clear feedback to the user about why they can't add a vault.
Consider expanding the message slightly to provide more context or guidance, such as:
- "vaultList.addVault.disabled.licenseViolation": "License limit exceeded.", + "vaultList.addVault.disabled.licenseViolation": "License limit exceeded. Please contact your administrator.",This additional information could help users understand what action they can take next.
frontend/src/i18n/de-DE.json (1)
248-248
: Approve with minor grammatical correctionThe new entry "vaultList.addVault.disabled.missingPermission" is appropriate and aligns with the PR objectives. However, there's a small grammatical error in the German text.
Please correct the grammatical error in the German text:
- "vaultList.addVault.disabled.missingPermission": "Die fehlt die Berechtigung zur Erstellung von Tresoren.", + "vaultList.addVault.disabled.missingPermission": "Dir fehlt die Berechtigung zur Erstellung von Tresoren.",This change replaces "Die fehlt" with "Dir fehlt", which is the correct German grammar for "You lack" or "You're missing".
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (3)
- frontend/src/components/VaultList.vue (4 hunks)
- frontend/src/i18n/de-DE.json (1 hunks)
- frontend/src/i18n/en-US.json (1 hunks)
🧰 Additional context used
🔇 Additional comments (6)
frontend/src/components/VaultList.vue (2)
101-101
: LGTM! Good user experience consideration.The conditional rendering of the empty vault list description based on
canCreateVaults
is a thoughtful addition. It ensures that users without the permission to create vaults don't see potentially confusing or irrelevant information, aligning well with the PR objectives.
150-150
: LGTM! Addressed past review comment.Initializing
isAdmin
withfalse
is a good practice. It prevents potential undefined behavior in the template and addresses the concern raised in the past review comments.frontend/src/i18n/en-US.json (2)
249-249
: Excellent addition! Aligns perfectly with PR objectives.This new entry for the missing permission scenario is well-implemented. It follows the established naming conventions and provides clear feedback to the user. The message content directly addresses the PR objectives by informing users about their permission status for vault creation.
This implementation also aligns with the suggestion made in the PR comments about adding a tooltip to the disabled "Add" button. It provides the necessary text for such a tooltip, enhancing the user experience by explaining why the action is unavailable.
248-249
: Summary: Effective implementation of user feedback for vault creation restrictionsThe two new entries added to this localization file effectively address the PR objectives by providing clear messages for scenarios where vault creation is restricted. These additions enhance the user experience by offering immediate feedback about license limitations and permission issues.
The changes are minimal yet impactful, seamlessly integrating with the existing localization structure. They lay the groundwork for implementing the tooltip suggestion mentioned in the PR comments, which will further improve the application's usability.
frontend/src/i18n/de-DE.json (2)
247-247
: LGTM: Clear message for license violationThe new entry "vaultList.addVault.disabled.licenseViolation" with the value "Lizenz überschritten." is a clear and concise message in German, indicating that the license limit has been exceeded. This aligns well with the PR objectives of implementing role-based access for vault creation.
247-248
: Summary: New translations align with PR objectivesThe two new entries added to the
vaultList
section of the German localization file effectively support the implementation of role-based access for vault creation, as outlined in the PR objectives. These additions will provide clear feedback to users when they are unable to create vaults due to license violations or missing permissions.The changes are consistent with the existing structure and naming conventions in the file, enhancing the user experience by providing appropriate localized messages.
The fallback is (currently) only used in case of `onMissingVault=REQUIRE_REALM_ROLE`, when no vault role exists yet
* allowing any user to modify a owned vault * allowing only users with `create-vaults` role to create vault * allowing any user to claim ownership (if they can prove worthy)
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.
Actionable comments posted: 2
🧹 Outside diff range and nitpick comments (4)
backend/src/main/java/org/cryptomator/hub/filters/VaultRole.java (1)
36-42
: LGTM: NewrealmRole()
method enhances role-based access controlThe addition of the
realmRole()
method to theVaultRole
annotation is well-implemented and documented. It provides a flexible way to specify additional realm roles required for access, which aligns with the PR's objectives.Consider adding a brief example in the Javadoc to illustrate how this method can be used in conjunction with
onMissingVault()
. This could help developers quickly understand its application. For instance:/** * ... * @return realm role required to access the annotated resource. * * Example usage: * @VaultRole(onMissingVault = OnMissingVault.REQUIRE_REALM_ROLE, realmRole = "create-vaults") */backend/src/main/java/org/cryptomator/hub/api/VaultResource.java (3)
391-392
: LGTM! Role-based access control for vault creation implemented.The new
@VaultRole
annotation with therealmRole = "create-vaults"
parameter effectively implements the requested "create-vaults" role from issue #206. This change ensures that only users with the appropriate permissions can create new vaults.Consider adding a comment explaining the role requirements for clarity:
+ // Requires "user" role for authentication and either "OWNER" role for existing vaults or "create-vaults" realm role for new vaults @RolesAllowed("user") // general authentication. VaultRole filter will check for specific access rights @VaultRole(value = VaultAccess.Role.OWNER, onMissingVault = VaultRole.OnMissingVault.REQUIRE_REALM_ROLE, realmRole = "create-vaults")
Line range hint
463-464
: LGTM! Improved security for vault ownership claims.The new check for the existence of
vault.authenticationPublicKey
prevents multiple users from claiming ownership of the same vault. This is a good security improvement.Consider adding a comment to explain the significance of this check:
+ // If authenticationPublicKey is null, the vault has already been claimed by another user var authPubKey = vault.getAuthenticationPublicKeyOptional().orElseThrow(() -> new ClientErrorException(Response.Status.CONFLICT));
Line range hint
1-563
: Overall, the changes look good and address the PR objectives.The implementation of the "create-vaults" role and the improvements to the vault ownership claim process are well-executed. These changes enhance the security and control over vault management, aligning with the requirements outlined in issue #206.
Consider documenting these new role-based access controls and the vault ownership claim process in the project's technical documentation or API documentation to ensure that other developers and potential API consumers are aware of these security measures.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (4)
- backend/src/main/java/org/cryptomator/hub/api/VaultResource.java (1 hunks)
- backend/src/main/java/org/cryptomator/hub/filters/VaultRole.java (1 hunks)
- backend/src/main/java/org/cryptomator/hub/filters/VaultRoleFilter.java (2 hunks)
- backend/src/test/java/org/cryptomator/hub/filters/VaultRoleFilterTest.java (5 hunks)
🧰 Additional context used
🔇 Additional comments (3)
backend/src/main/java/org/cryptomator/hub/filters/VaultRole.java (2)
34-34
: LGTM: New enum value adds flexibility for role-based access controlThe addition of
REQUIRE_REALM_ROLE
to theOnMissingVault
enum enhances the annotation's capability to handle cases where a vault doesn't exist. This change aligns well with the PR's objective of introducing a new role for vault creation, allowing for more granular control over access permissions.
34-42
: Verify proper usage of new role-based access control featuresThe additions to the
VaultRole
annotation significantly enhance the system's capability for fine-grained access control, particularly for vault creation. This aligns well with the PR objectives and provides a more flexible and potentially more secure way to manage permissions.To ensure these changes are leveraged effectively:
- Verify that all relevant endpoints are updated to use the new
REQUIRE_REALM_ROLE
option where appropriate.- Ensure that the
create-vaults
role is properly assigned in Keycloak as mentioned in the PR description.- Consider adding integration tests to verify the behavior of endpoints using this new access control mechanism.
To help verify the proper usage of these new features, you can run the following script:
This script will help identify where the new features are being used and potentially misused, allowing for a more thorough review of their implementation across the codebase.
✅ Verification successful
Verified proper usage of new role-based access control features
All usages of
REQUIRE_REALM_ROLE
andrealmRole
have been properly implemented without any detected misuses. The annotation updates align with the intended fine-grained access control enhancements.
VaultResource.java
usesREQUIRE_REALM_ROLE
withrealmRole = "create-vaults"
VaultRoleFilterTest.java
usesREQUIRE_REALM_ROLE
withrealmRole = "foobar"
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for usage of new REQUIRE_REALM_ROLE and realmRole features # Test 1: Check for usage of REQUIRE_REALM_ROLE echo "Checking for usage of REQUIRE_REALM_ROLE:" rg --type java "onMissingVault\s*=\s*OnMissingVault\.REQUIRE_REALM_ROLE" # Test 2: Check for usage of realmRole echo "Checking for usage of realmRole:" rg --type java "realmRole\s*=\s*\"[^\"]+\"" # Test 3: Check for potential misuse (realmRole without REQUIRE_REALM_ROLE) echo "Checking for potential misuse of realmRole:" rg --type java "realmRole\s*=\s*\"[^\"]+\"" -C 5 | rg -v "onMissingVault\s*=\s*OnMissingVault\.REQUIRE_REALM_ROLE"Length of output: 3623
backend/src/test/java/org/cryptomator/hub/filters/VaultRoleFilterTest.java (1)
179-205
: Excellent addition of tests for realm role verificationThe new
RequireRealmRole
nested class effectively tests scenarios where a user lacks or possesses the required realm role when accessing a non-existing vault. This enhances test coverage and ensures that theOnMissingVault.REQUIRE_REALM_ROLE
behavior is correctly implemented.
backend/src/test/java/org/cryptomator/hub/filters/VaultRoleFilterTest.java
Show resolved
Hide resolved
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.
LGTM, nice implementation 👍
I think we need to document this in as many places as possible:
If you want to have Cryptomator Hub in the same functionality as before this, just set the create-vaults
role as the default role for the realm:
The new default is create-vaults
is only possible for users with the admin role or when explicitly applied to the user/group/identity provider or set as default for the realm.
This PR fixes #206 by introducing the
create-vaults
role.Note that the
dev-realm
adds this role only for usersadmin
,alice
andbob
, while the userscarol
,dave
anderin
are not allowed to create vaults.