-
Notifications
You must be signed in to change notification settings - Fork 25k
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 cors support to NioHttpServerTransport #30827
Conversation
Pinging @elastic/es-core-infra |
This mostly just copies work over from the netty module. In the future I will work on extracting some of this code into a common classes. But the most straightforward way to implement this at the moment is to copy (as it requires a netty dependency which cannot live in server). |
@elastic/es-core-infra @jasontedor @tbrooks8 I don't think I can review this I am lacking knowledge of CORS. |
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 left a few comments.
} | ||
|
||
/** | ||
* Determines if cookies are supported for CORS requests. |
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 hate to get pedantic on Javadoc, but within CORS, credentials refers to more than just cookies.
Per: https://www.w3.org/TR/cors/#user-credentials
The term user credentials for the purposes of this specification means cookies, HTTP authentication, and client-side SSL certificates that would be sent based on the user agent's previous interactions with the origin
final String originHeaderVal; | ||
if (config.isAnyOriginSupported()) { | ||
originHeaderVal = ANY_ORIGIN; | ||
} else if (config.isOriginAllowed(originHeader) || isSameOrigin(originHeader, request.headers().get(HttpHeaderNames.HOST))) { |
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.
This isSameOrigin
check seems out of place.
It seems that we implicity treat any origins on the same host as being allowed, even if the browser thinks it's cross-origin.
Since an origin consists of the triplet ( scheme , host , port )
, this would allow any web-app running on the same host to have access the ES server (if CORS is enabled) regardless of its actual origin (scheme/port).
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.
Opened an issue (#30988)
|
||
private boolean validateOrigin() { | ||
if (config.isAnyOriginSupported()) { | ||
return true; |
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.
This will include null
origins, which I think is the right thing to do, but probably should be explicitly stated in the javadocs for isAnyOriginSupported
.
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 updated the java doc.
} | ||
|
||
if ("null".equals(origin) && config.isNullOriginAllowed()) { | ||
return true; |
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 think this should be something more like:
if ("null".equals(origin)) {
return config.isNullOriginAllowed();
}
I don't think it makes sense to fall through to pattern checking the origin is null, and null is not allowed.
That is, if we have an explicit config option for null
handling, then that should be the only way to determine whether null is allowed.
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 actually do not think this is correct based on how we have implemented Cors. Our setup, means that config.isNullOriginAllowed
will always be false. We never modify that config. We only allow configuring config.isOriginAllowed(...)
through http.cors.allow-origin
. So if the user wants to allow null, that must be in the regex. We will only evaluate that regex if we fall through.
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 actually do not think this is correct based on how we have implemented Cors.
This is an intricacy of the fact that the CorsConfig
class that we have copied over from netty allows a lot of different configs. But we really only use the pattern matching.
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 have a (non-blocking) concern about copying code across with the obligations to maintain it, but only use part of it.
Is there an argument for why we're keeping parts of this that we don't actually use?
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'm not sure why we took the approach we did. It is on my roadmap to change at some point.
I have started playing around with implementing Cors on our side opposed to Netty's side (https://github.com/tbrooks8/elasticsearch/tree/cors_without_netty). Essentially we would do the Cors logic AFTER we have turned a netty http request into a RestRequest
. And then nio / netty4 modules would use the same code base (as the logic would live in server
). If that turns out to be too complicated, I can explore paring down what we use from netty.
Thanks for the feedback @tvernum. I want to provide some context for this PR. It is just copying our work form the netty module and modifying it to work with nio facilities. All the logic is the same.
Additionally these are pretty much pulled from the netty project ( I guess my point here is: all of the feedback you provided applies to both implementations. I opened an issue for one of your points. I think that should be addressed separately. On the two documentation points I made slight modifications to the documentation from netty. As that was pretty simple. |
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'm happy with this as is, but I do think we should go through and remove the bits that we don't actually need/use. But that doesn't have to happen in this PR.
* elastic/master: Add cors support to NioHttpServerTransport (elastic#30827) [DOCS] Fixes security example (elastic#31082) Allow terms query in _rollup_search (elastic#30973) Removing erroneous repeat Adapt bwc versions after backporting elastic#30983 to 6.4
* ccr: [DOCS] Creates rest-api folder in docs [Rollup] Disallow index patterns that match the rollup index (elastic#30491) Replace exact numDocs by soft-del count in SegmentInfo (elastic#31086) Upgrade to Lucene-7.4.0-snapshot-0a7c3f462f (elastic#31073) Add cors support to NioHttpServerTransport (elastic#30827) [DOCS] Fixes security example (elastic#31082) Allow terms query in _rollup_search (elastic#30973) Removing erroneous repeat Adapt bwc versions after backporting elastic#30983 to 6.4 [Tests] Muting RatedRequestsTests#testXContentParsingIsNotLenient TEST: Retry synced-flush if ongoing ops on primary (elastic#30978) Fix docs build. Only auto-update license signature if all nodes ready (elastic#30859) Add BlobContainer.writeBlobAtomic() (elastic#30902) Add a doc value format to binary fields. (elastic#30860)
* ccr: [DOCS] Creates rest-api folder in docs [Rollup] Disallow index patterns that match the rollup index (elastic#30491) Replace exact numDocs by soft-del count in SegmentInfo (elastic#31086) Upgrade to Lucene-7.4.0-snapshot-0a7c3f462f (elastic#31073) Add cors support to NioHttpServerTransport (elastic#30827) [DOCS] Fixes security example (elastic#31082) Allow terms query in _rollup_search (elastic#30973) Removing erroneous repeat Adapt bwc versions after backporting elastic#30983 to 6.4 [Tests] Muting RatedRequestsTests#testXContentParsingIsNotLenient TEST: Retry synced-flush if ongoing ops on primary (elastic#30978) Fix docs build. Only auto-update license signature if all nodes ready (elastic#30859) Add BlobContainer.writeBlobAtomic() (elastic#30902) Add a doc value format to binary fields. (elastic#30860)
This is related to #28898. This commit adds cors support to the nio http
transport. Most of the work is copied directly from the netty module
implementation. Additionally, this commit adds tests for the nio http
channel.