Skip to content
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

WIP: fix(cors) allow pre-flight requests to options / trace / connect endpoints #4899

Closed
wants to merge 1 commit into from
Closed

WIP: fix(cors) allow pre-flight requests to options / trace / connect endpoints #4899

wants to merge 1 commit into from

Conversation

eshepelyuk
Copy link

@eshepelyuk eshepelyuk commented Aug 13, 2019

Summary

Fix cors plugin configuration and behavior for processing pre-flight requests to OPTIONS / TRACE / CONNECT endpoints

Full changelog

  • allow pre-flight requests to options / trace / connect endpoints

Issues resolved

Fix #4898

@CLAassistant
Copy link

CLA assistant check
Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
You have signed the CLA already but the status is still pending? Let us recheck it.

@intpp
Copy link

intpp commented Aug 13, 2019

👍

@eshepelyuk eshepelyuk changed the title fix(cors) allow pre-flight requests to options endpoints WIP: fix(cors) allow pre-flight requests to options endpoints Aug 13, 2019
Copy link
Member

@thibaultcha thibaultcha left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the patch! Would you also contribute test cases for this fix please?

kong/plugins/cors/handler.lua Outdated Show resolved Hide resolved
kong/plugins/cors/schema.lua Outdated Show resolved Hide resolved
@eshepelyuk
Copy link
Author

Thanks for the patch! Would you also contribute test cases for this fix please?

sure, just waiting for the design approval (some sort of message or anything), that means the team understands and welcomes those changes and possible implications ( i believe, existing cients can be affected)

@thibaultcha
Copy link
Member

@eshepelyuk Yes, the chosen approach is fine.

@eshepelyuk
Copy link
Author

@thibaultcha should I rebase on master or on particular release branch ?

@thibaultcha
Copy link
Member

@eshepelyuk We are currently in feature freeze with the upcoming 1.3.0 release (next Wednesday), but given this is a fix (and rather minimal), we could still ship it by then if it is ready (no rush, if not on Wednesday, it will ship next time around) cc @Kong/team-core.

We always submit fixes against master (as per our contribution guidelines), so better rebase the PR against it. The patch would apply cleanly in either branch anyway.

Thanks for taking care of it! Truly appreciated, this is a nice fix.

@eshepelyuk eshepelyuk changed the title WIP: fix(cors) allow pre-flight requests to options endpoints WIP: fix(cors) allow pre-flight requests to options / trace / connect endpoints Aug 17, 2019
@@ -0,0 +1,3 @@
return {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@eshepelyuk A minor concern about this PR: the api.lua module name has a special meaning in plugins (it is used to specify customization to the generated Admin API endpoints). Please rename this module to something else to avoid namespace clashes.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In fact, better not introduce such a new module at all. I understand that the intent is to not duplicate the list between the plugin's code and tests, but we actually would rather duplicate it. This avoids accidental changes to the list going unnoticed (since they need to be updated in the tests and in the code). This is a pattern that this codebase has been following for a long time now.

@hishamhm
Copy link
Contributor

@eshepelyuk Left a minor change request, otherwise i think this PR is good to go!

@@ -181,7 +181,9 @@ end


function CorsHandler:access(conf)
if kong.request.get_method() ~= "OPTIONS" then
if not (kong.request.get_method() == "OPTIONS"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

style: please remove the extra set of parenthesis around this expression. They are not necessary.

@@ -0,0 +1,3 @@
return {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In fact, better not introduce such a new module at all. I understand that the intent is to not duplicate the list between the plugin's code and tests, but we actually would rather duplicate it. This avoids accidental changes to the list going unnoticed (since they need to be updated in the tests and in the code). This is a pattern that this codebase has been following for a long time now.

@@ -212,7 +214,6 @@ function CorsHandler:access(conf)
end

local methods = conf.methods and concat(conf.methods, ",")
or "GET,HEAD,PUT,PATCH,POST,DELETE"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please do not remove the fallback here (it doesn't seem like config.methods is properly labelled as being required). And if it is, then we'd need to update the above assignment conditions anyway. But better stay safe here, we are shipping this patch as a fix without an RC cycle, let's not forget.

assert.is_nil(res.headers["Access-Control-Max-Age"])
assert.is_nil(res.headers["Vary"])
end)
-- TODO rewrite test
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is going to be a blocker. Can you rewrite the test, if it needs to? And if not, can you elaborate on what the issue is? Nonetheless, we cannot just disable a regression test just before shipping a major release.

["Access-Control-Request-Headers"] = "origin,accepts",
["Access-Control-Request-Method"] = "GET",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would you mind pointing us to the test that asserts the behavior fixed by this PR (i.e. that non-preflight OPTIONS requests get properly proxied after a preflight request)?

end)
end)
end)

describe("methods in cors schema", function()
for _,method in ipairs({"HEAD", "GET", "POST", "PUT", "PATCH", "DELETE", "OPTIONS", "TRACE", "CONNECT"}) do
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

style: missing a space after , and in the table definition ({ "HEAD", ... }).

@thibaultcha thibaultcha added this to the 1.3.0 milestone Aug 20, 2019
@thibaultcha thibaultcha self-assigned this Aug 20, 2019
@thibaultcha
Copy link
Member

Manually merged with the appropriate tweaks. Thank you!

@eshepelyuk
Copy link
Author

Guys ! What are you doing ? The PR is not completed and i am working on tests :(((

@hishamhm
Copy link
Contributor

@eshepelyuk Don't worry! :) We really wanted your fix to go into 1.3.0 which is due to release today, so we took it to ourselves to make the final tweaks and get it merged. So this is marked as "closed" but it was really accepted — it's already live in the master branch and in the release/1.3.0 branch as well. If you have any changes to propose beyond what's in master, feel free to open another PR!

Thank you for contributing!

(Also, could you sign the CLA at https://cla-assistant.io/Kong/kong?pullRequest=4899 ? Thank you!)

@hishamhm
Copy link
Contributor

hishamhm commented Aug 21, 2019

@eshepelyuk Also, you need to sign the CLA using the account that owns the email that's in the commit: eshepelyuknewagesol — thanks!

@eshepelyuk
Copy link
Author

@eshepelyuk Also, you need to sign the CLA using the account that owns the email that's in the commit: eshepelyuknewagesol — thanks!

@hishamhm I tried it dozen of times and although I was told that SLA was signed - it's still pending :(
Am I missing smth ?

@hishamhm
Copy link
Contributor

@eshepelyuk I think the problem might be that you used two different Github accounts? Perhaps try logging in a private browser window, log into Github with the other account and then access https://cla-assistant.io/Kong/kong?pullRequest=4899 — let's hope this works!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Support for pre-flight requests to OPTIONS endpoints in cors plugin
5 participants