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

CORS headers duplicated when connecting to standby server in HA mode #3485

Closed
nathanhoel opened this issue Oct 24, 2017 · 4 comments · Fixed by #3501
Closed

CORS headers duplicated when connecting to standby server in HA mode #3485

nathanhoel opened this issue Oct 24, 2017 · 4 comments · Fixed by #3501
Milestone

Comments

@nathanhoel
Copy link

nathanhoel commented Oct 24, 2017

Environment:

  • Vault Version: Vault v0.8.1 ('8d76a41854608c547a233f2e6292ae5355154695')
  • Operating System/Architecture: Alpine (Vault Docker image tag: 0.8.1)

Vault Config File:

{
  "listener": [
    {
      "tcp": {
        "address": "0.0.0.0:8200",
        "cluster_address": "0.0.0.0:8201",
        "tls_cert_file": "/vault/certs/vault.crt",
        "tls_key_file": "/vault/certs/vault.key"
      }
    },
    {
      "tcp": {
        "address": "0.0.0.0:8280",
        "tls_disable": 1
      }
    }
  ],
  "telemetry": {
    "statsd_address": "datadog.domain.vpc:8125"
  },
  "default_lease_ttl": "168h",
  "max_lease_ttl": "720h"
}

Startup Log Output:

==> Vault server configuration:

                     Cgo: disabled
         Cluster Address: https://staging-1a.vault.domain.com:8080
              Listener 1: tcp (addr: "0.0.0.0:8200", cluster address: "0.0.0.0:8201", tls: "enabled")
              Listener 2: tcp (addr: "0.0.0.0:8280", cluster address: "0.0.0.0:8281", tls: "disabled")
               Log Level: info
                   Mlock: supported: true, enabled: true
        Redirect Address: https://staging-1a.vault.domain.com:443
                 Storage: dynamodb (HA available)
                 Version: Vault v0.8.1
             Version Sha: 8d76a41854608c547a233f2e6292ae5355154695

==> Vault server started! Log data will stream in below:

Expected Behavior:
Making a vault API auth request to /v1/auth/aws/login within a browser using CORS with allowed origins set to * and the appropriate content types configured would allow the browser to authenticate.

Actual Behavior:
The OPTIONS request is successful but the POST request to /v1/auth/aws/login returns duplicate headers from vault.
These 3 headers are duplicated access-control-allow-origin, cache-control, vary.
The duplicate access-control-allow-origin causes the browser to ignore the success request and give this error.

Failed to load https://staging.vault.domain.com/v1/auth/aws/login: The 'Access-Control-Allow-Origin' header contains multiple values 'https://vault-ui-staging.domain.com, https://vault-ui-staging.domain.com', but only one is allowed. Origin 'https://vault-ui-staging.domain.com' is therefore not allowed access.

Steps to Reproduce:
I believe this occurs because of the High Availability and request forwarding.
If you connect to a stand-by vault server while using CORS request headers this error occurs.
Whenever someone connects to the active server while using CORS the duplicate headers are not present.

Important Factoids:
You may notice that we connect to staging.vault.domain.com not staging-1a.vault.domain.com. We use a CNAME DNS entry to round robin between the nodes. We are changing our DNS strategy in the mean time to avoid the stand-by server.

Opinion
Forgive me as I am quite unfamiliar with GO and GO libs - but I believe that this line
https://github.com/hashicorp/vault/blob/master/http/handler.go#L87
Where it wraps the response in CORS headers may be the issue when the request was forwarded. I couldn't determine through code inspection alone but it appears as if the headers from the forwarded request would still contain the CORS headers and then the forwarding host will wrap the response with CORS headers again.

If I am correct my opinion is that the CORS headers from the remote host should be used and the forwarding host should not attempt to wrap the response on CORS headers.

@jefferai
Copy link
Member

Any chance you can build from the issue-3485 branch and see if it's fixed for you? It seems to be fine in my testing but I'm not coming from a browser.

@jefferai jefferai added this to the 0.8.4 milestone Oct 27, 2017
@nathanhoel
Copy link
Author

Wonderful - I will be able to test in our staging environment tomorrow to tell you for sure.
I feel fairly confident about it.

jefferai added a commit that referenced this issue Oct 27, 2017
we want to replace anything that might be there (e.g. for request
forwarding and content-type).

Hopefully fixes #3485
@jefferai
Copy link
Member

Note that I made a minor force push to the branch -- if you have checked it out before right now, please make sure to update.

@nathanhoel
Copy link
Author

It appears the branch fixes our issue, awesome!

jefferai added a commit that referenced this issue Nov 2, 2017
…lly (#3501)

we want to replace anything that might be there (e.g. for request
forwarding and content-type).

Hopefully fixes #3485
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 a pull request may close this issue.

2 participants