-
Notifications
You must be signed in to change notification settings - Fork 122
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
Fix to enable changing the permission of internal repositories. #898
Conversation
Motivation: Internal repositories are initially created with the [internal](https://github.com/line/centraldogma/blob/0cf273402d70773e0aab1e2b858111a1c1c0f22c/server/src/main/java/com/linecorp/centraldogma/server/metadata/PerRolePermissions.java#L61) permission, and I previously restricted the ability to modify this permission. However, users may have valid reasons to adjust the permission settings. Modifications: - Implemented functionality to change the permission of internal repositories. - Note: The guest role remains restricted from having any permission on internal repositories. Result: - You can now have the capability to modify the permission settings for internal repositories, excluding the guest role.
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## main #898 +/- ##
============================================
- Coverage 66.11% 66.07% -0.04%
+ Complexity 3407 3404 -3
============================================
Files 363 363
Lines 14117 14121 +4
Branches 1509 1511 +2
============================================
- Hits 9333 9330 -3
- Misses 3921 3925 +4
- Partials 863 866 +3 ☔ View full report in Codecov by Sentry. |
if (!guest.isEmpty()) { | ||
throw new UnsupportedOperationException( | ||
"can't give a permission to guest for internal repository: " + repoName); |
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.
For consistency with the permission of internalPermissions
, should we disallow giving permissions to MEMBER
for internal repositories?
centraldogma/server/src/main/java/com/linecorp/centraldogma/server/metadata/PerRolePermissions.java
Lines 55 to 56 in 0cf2734
private static final PerRolePermissions internalPermissions = | |
new PerRolePermissions(READ_WRITE, NO_PERMISSION, NO_PERMISSION); |
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 believed we had previously discussed this matter and reached a consensus to delegate permission-granting authority to the owner for members. 😉
internalPermissions
is assigned to internal repositories upon creation, and the owner has the discretion to change it at will. While I'm not strongly opposed, I see no compelling reason to restrict granting permissions to members.
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.
Understood.
I was confused that the permission could be also granted to dogma
repo.
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.
Technically, I believe allowing MEMBER access to dogma
can potentially allow MEMBERs to "kick" OWNERs out of projects.
I don't really know the distinction of owner and member though. If the meaning is simply to add an extra layer of authority, I guess the current change is fine.
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.
Ah, got it. The dogma repo is restricted from being accessed by any user, so I initially thought this would suffice:
Lines 78 to 83 in 0cf2734
if (user.isAdmin()) { | |
return unwrap().serve(ctx, req); | |
} | |
if (Project.REPO_DOGMA.equals(repoName)) { | |
return throwForbiddenResponse(ctx, projectName, repoName, "administrator"); | |
} |
However, for clarity, I believe it's beneficial to explicitly allow changes only to the meta repository.
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.
Thanks, @minwoox!
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.
👍 👍 👍
final Set<Permission> guest = perRolePermissions.guest(); | ||
if (!guest.isEmpty()) { | ||
throw new UnsupportedOperationException( | ||
"can't give a permission to guest for internal repository: " + repoName); |
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.
Since I believe this exception will be directly exposed to the end user
"can't give a permission to guest for internal repository: " + repoName); | |
"Can't give a permission to guest for internal repository: " + repoName); |
if (!guest.isEmpty()) { | ||
throw new UnsupportedOperationException( | ||
"can't give a permission to guest for internal repository: " + repoName); |
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.
Technically, I believe allowing MEMBER access to dogma
can potentially allow MEMBERs to "kick" OWNERs out of projects.
I don't really know the distinction of owner and member though. If the meaning is simply to add an extra layer of authority, I guess the current change is fine.
Lines 78 to 83 in 0cf2734
|
Thanks for reviewing. 😉 |
Motivation: Despite having the necessary permissions after line#898, members were unable to access the meta repository. Modifications: - Implemented a fix to ensure that members can access the meta repository as intended. Result: - Members with appropriate permissions can now successfully access the meta repository.
Motivation: Despite having the necessary permissions after #898, members were unable to access the meta repository. Modifications: - Implemented a fix to ensure that members can access the meta repository as intended. Result: - Members with appropriate permissions can now successfully access the meta repository.
Motivation:
Internal repositories are initially created with the internal permission, and I previously restricted the ability to modify this permission. However, users may have valid reasons to adjust the permission settings.
Modifications:
Result: