-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Added authorization for JsonRpc methods #10934
Added authorization for JsonRpc methods #10934
Conversation
67f018e
to
e5ee146
Compare
e5ee146
to
32852e3
Compare
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.
direction of this PR looks good to me.
import org.eclipse.che.multiuser.api.permission.server.jsonrpc.RemoteSubscriptionPermissionManager; | ||
import org.eclipse.che.multiuser.api.permission.server.model.impl.AbstractPermissions; | ||
|
||
/** @author Sergii Leshchenko */ |
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.
Please describe purpose of this class in javadoc
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.
Do we need a test for this class?
4ff8bdb
to
91fc90d
Compare
@skabashnyuk @garagatyi PR is ready to review, please take a look. |
ci-test |
ci-test build report: |
ci-test |
a38532f
to
7f3c55b
Compare
ci-test build report: |
96ff276
to
30d1735
Compare
ci-test |
As far as I understand there is no default permissions filter in this PR. This leads us to a situation when new JSON_RPC methods are not secure by default, but rather insecure by default. I find it a popular practice in modern software to make stuff secure by default since it leads to less critical vulnerabilities. Please, consider adding such an approach before merging this PR. |
I thought about it and decided to implement easier way, where there is no default permissions filter since the same situation as we have with our REST API service/methods (they are public by default).
I would merge this PR as it is since it introduces the authorization mechanism for Json Rpc methods and it can be improved in a separated issue and PR. BTW It's much secure to have a current approach than in master branch. I'll create a separate issue if you're OK with that. |
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, well done!
String currentUserId = EnvironmentContext.getCurrent().getSubject().getUserId(); | ||
|
||
try { | ||
AbstractPermissions permissions = |
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.
Can you add a comment to the code with the explanation of why this part is implemented in this way?
@sleshchenko I'm OK with implementing the secure-by-default approach in a separate issue. Hope your team would be able to prioritize such a task |
ci-test build report: |
ci-test |
@garagatyi I've created an issue to make resources exposed by REST and WebSocket private by default #11007. Feel free to comment or edit. |
ci-test build report: |
ci-test |
ci-test build report: |
It allows to build a project without tests compiling
db03ee2
to
e62dbb7
Compare
ci-test build report: |
What does this PR do?
Here is an example of an invocating JsonRpc method and remote subscribing without required permissions:

What issues does this PR fix or reference?
#10861
Release Notes
Added authorization checks before calling of JsonRpc methods
Docs PR
N/A