-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
Restrict ES data proxy to msearch and search #13020
Conversation
@@ -26,15 +26,15 @@ describe('formatMsg', function () { | |||
data: { | |||
statusCode: 403, | |||
error: 'Forbidden', | |||
message: '[security_exception] action [indices:data/read/mget] is unauthorized for user [user]' | |||
message: '[security_exception] action [indices:data/read/msearch] is unauthorized for user [user]' |
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.
These references didn't have to be updated, but I wanted to remove all possible references to mget from client-side code to make future grepping a little easier.
We are only using msearch and search on this proxy, so there's no reason for us to expose more capabilities than this. Ultimately we want to move all functionality like this to REST API rather than being a straight up proxy, so this will help proxy usage not expand throughout upcoming versions until it can be removed entirely.
Doesn't have to be part of this PR, but does this mean we could get rid of the DocSourceProvider including the data strategy? |
@tylersmalley I'm almost positive we can, but I wanted to run through it with Spencer to be certain |
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
That works for me @epixa, without mget that provider will error out so it might be worth going back and cleaning up the code. |
We are only using msearch and search on this proxy, so there's no reason
for us to expose more capabilities than this. Ultimately we want to move
all functionality like this to REST API rather than being a straight up
proxy, so this will help proxy usage not expand throughout upcoming
versions until it can be removed entirely.