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

Date header not accessible to CORS browser clients, missing Access-Control-Expose-Headers #33231

Closed
jwforres opened this issue Sep 21, 2016 · 5 comments
Labels
area/apiserver sig/api-machinery Categorizes an issue or PR as relevant to SIG API Machinery.

Comments

@jwforres
Copy link
Contributor

v1.4.0-beta.3+d19513f

If a UI is hosted on a different domain than the API, and that UI hostname has been whitelisted as an allowed CORS origin, it should be able to access the Date header being returned by the API.

However, the CORS spec requires any headers that are not simple must be included in a header called Access-Control-Expose-Headers or the javascript in the page will not be able to access the headers even if they are returned by the server.

This should just be a matter of adding Access-Control-Expose-Headers in the CORS handler

func CORS(handler http.Handler, allowedOriginPatterns []*regexp.Regexp, allowedMethods []string, allowedHeaders []string, allowCredentials string) http.Handler {

@jwforres
Copy link
Contributor Author

jwforres commented Sep 21, 2016

cc @smarterclayton I found this trying to fix the clock skew problem

@k8s-github-robot k8s-github-robot added area/apiserver sig/api-machinery Categorizes an issue or PR as relevant to SIG API Machinery. labels Sep 21, 2016
@dims
Copy link
Member

dims commented Sep 22, 2016

@jwforres i can take a stab at a quick change Access-Control-Expose-Headers (support section 6.1.4 of https://www.w3.org/TR/cors/#resource-requests). If i a file a WIP PR, will you be able to build it and test it? Please let me know, if not i can try to setup an environment.

@dims
Copy link
Member

dims commented Sep 22, 2016

oh and which set of http headers need to be exposed?

dims added a commit to dims/kubernetes that referenced this issue Sep 22, 2016
Our typical HTTP Response has a "Date" Header, if we don't add an
additional http header "Access-Control-Expose-Headers: Date" then
the browser based clients cannot use the Date HTTP Header.

Fixes kubernetes#33231
@jwforres
Copy link
Contributor Author

I'm not aware of any other special headers being sent, Date should be enough for now

I'm not really set up to run just kubernetes right now, I could cherry-pick the change into openshift's vendor of kube 1.4 and try it there if you want?

@dims
Copy link
Member

dims commented Sep 22, 2016

Sure @jwforres please try the PR and let me know.

dims added a commit to dims/kubernetes that referenced this issue Sep 28, 2016
Our typical HTTP Response has a "Date" Header, if we don't add an
additional http header "Access-Control-Expose-Headers: Date" then
the browser based clients cannot use the Date HTTP Header.

Fixes kubernetes#33231
k8s-github-robot pushed a commit that referenced this issue Sep 29, 2016
Automatic merge from submit-queue

Support Access-Control-Expose-Headers in CORS Handler

Our typical HTTP Response has a "Date" Header, if we don't add an
additional http header "Access-Control-Expose-Headers: Date" then
the browser based clients cannot use the Date HTTP Header.

Fixes #33231

**Release note**:
<!--  Steps to write your release note:
1. Use the release-note-* labels to set the release note state (if you have access) 
2. Enter your extended release note in the below block; leaving it blank means using the PR title as the release note. If no release note is required, just write `NONE`. 
-->
```release-note
When CORS Handler is enabled, we now add a new HTTP header named "Access-Control-Expose-Headers" with a value of "Date". This allows the "Date" HTTP header to be accessed from XHR/JavaScript.
```
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/apiserver sig/api-machinery Categorizes an issue or PR as relevant to SIG API Machinery.
Projects
None yet
Development

No branches or pull requests

3 participants