-
Notifications
You must be signed in to change notification settings - Fork 585
conformance: add test to check for proper cors allow-credentials behvior #3990
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
conformance: add test to check for proper cors allow-credentials behvior #3990
Conversation
/retest |
/ok-to-test |
/retest |
/test CRD Validation / CEL (v1.33.0, experimental) (pull_request) |
@EyalPazz: The specified target(s) for
Use In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
/test all |
/cc @lianglli |
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.
origin := "https://app.example" | ||
|
||
testCases := []http.ExpectedResponse{ | ||
{ |
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.
nit: it's good to use the TestCaseName
here when you can. We kind of (ab)use it in various places to provide a description explaining the tests intent.
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.
Pascal or Camel case?
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.
Actually several of them are basically just descriptions with spaces and everything. We may even want to rename it Description
(or I suppose add Description
) but in the meantime, if you wanna just look how the bulk of them are done and follow that that's fine. We need to revisit these things (but that doesn't need to be done as part of this specific PR).
// Declare tc here to avoid loop variable | ||
// reuse issues across parallel tests. |
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.
We have a linter checking for this, right? 🤔
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 don't think so? are you talking about copyloopvar maybe?
|
||
var CORSAllowCredentialsBehavior = suite.ConformanceTest{ | ||
ShortName: "CORSAllowCredentialsBehavior", | ||
Description: "Validate ACA-Credentials responses", |
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 needs a better description, what is it doing, what is expected, what kind of validation will happen here
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.
Does this seem ok?
Validate ACA-Credentials responses, the gateway needs to return Access-Control-Allow-Credentials: true for credentialed CORS requests when enabled on the gateway, and omit it when disabled
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.
much better! thank you!
Features: []features.FeatureName{ | ||
features.SupportGateway, | ||
features.SupportHTTPRoute, | ||
features.SupportHTTPRouteCORS, |
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 reminds me: we don't have any other CORS test. Wouldn't be better to either add those tests as well (support Cors, then test authorization)? Maybe this test should cover the whole extension, eg.:
- different allowed origins - CORS doesn't support a list of origins, but we say we do on our API, so this should be tested, see: https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Access-Control-Allow-Origin and
gateway-api/apis/v1/httproute_types.go
Line 1377 in 110bcaf
// When the `AllowOrigins` field is configured with multiple origins, it - Does it support different methods? See
gateway-api/apis/v1/httproute_types.go
Line 1425 in 110bcaf
// AllowMethods indicates which HTTP methods are supported for accessing the - Does it respect the Header max age? See
gateway-api/apis/v1/httproute_types.go
Line 1563 in 110bcaf
MaxAge int32 `json:"maxAge,omitempty"`
My point is that while the authorization test is desired, we lack some basic CORS conformance test that I think could be part of this change
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.
(but also, if we feel comfortable with merging this and following up, just be sure to open an issue to track the lack of basic cors tests)
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.
don't mind either way — I just don't know if I'll have time in the next few days, so it depends on whether we want to get it merged now. @shaneutt
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.
okie, let's wait for Shane to chime in! thanks!
}, | ||
Response: http.Response{ | ||
StatusCode: 200, | ||
AbsentHeaders: []string{"Access-Control-Allow-Credentials"}, |
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 you wanna follow the same test as bellow here and check if the Access-Control-Allow-Origin reflects what you added?
/hold The test is will not work as of today, because the manifest sets a nullable field as false and confuses CEL and other parts. We may want to fix the CORS field to either be a string, or not be a bool pointer and accept it can be true or false, but not "nullable" |
/hold cancel |
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.
/approve
/lgtm
@EyalPazz mentioned not necessarily having any extra time in the above comments, so let's merge for now and we can follow-up 👍
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: EyalPazz, shaneutt The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
/kind test
/area conformance-test
What this PR does / why we need it:
Test for proper cors allow-credentials behavior, and add the CORS Feature
Which issue(s) this PR fixes:
Fixes #3946
Does this PR introduce a user-facing change?: