Staging returns multiple Access-Control-Allow-Origin headers

[Daniel Roesler]

Howdy,

I think something is buggy with the staging server for CORS requests.
When I request the directory via XHR request in javascript, the
staging server is returning to Access-Control-Allow-Origin headers.
Production is unaffected. Below are the troubleshooting curl
statements. Thoughts?

Staging:
==============================
$ curl -D - -H "Origin: https://example.com"
"https://acme-staging.api.letsencrypt.org/directory"
HTTP/1.1 200 OK
Server: nginx
Content-Type: application/json
Content-Length: 279
Access-Control-Allow-Origin: *
Access-Control-Expose-Headers: Link, Replay-Nonce
Access-Control-Max-Age: 86400
Replay-Nonce: fNlib7TXpYo8t5OuSPsDXBq61YZog4AUGcSgw3m4dL4
X-Frame-Options: DENY
Strict-Transport-Security: max-age=604800
Access-Control-Allow-Origin: *
Expires: Sun, 15 Nov 2015 20:41:21 GMT
Cache-Control: max-age=0, no-cache, no-store
Pragma: no-cache
Date: Sun, 15 Nov 2015 20:41:21 GMT
Connection: keep-alive
==============================

Production:
==============================
$ curl -D - -H "Origin: https://example.com"
"https://acme-v01.api.letsencrypt.org/directory"
HTTP/1.1 200 OK
Server: nginx
Content-Type: application/json
Content-Length: 263
Replay-Nonce: g5gJ7vlMmAg35fRFy_BKUoZO7Y556nFnzMPSWwMoBEA
X-Frame-Options: DENY
Strict-Transport-Security: max-age=604800
Access-Control-Allow-Origin: *
Expires: Sun, 15 Nov 2015 20:41:33 GMT
Cache-Control: max-age=0, no-cache, no-store
Pragma: no-cache
Date: Sun, 15 Nov 2015 20:41:33 GMT
Connection: keep-alive
==============================

-Daniel Roesler

[Daniel Roesler]

To follow up with this. It looks like production isn't including the
"Access-Control-Expose-Headers: Link, Replay-Nonce" header, either.

[Richard Barnes]

In your pasted output, it looks like both staging and prod are sending
ACAO. I think that's the desired behavior, so that someone could
write a web-based client.

> --
> You received this message because you are subscribed to the Google Groups "Let's Encrypt CA Development" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to ca-dev+un...@letsencrypt.org.
>

[Daniel Roesler]

Yes, both are sending it. However, browsers interpret the two ACAO
headers as "*, *". For example, when you paste the following into
Firefox's debug console, you will get the following error responses.

========Command===========
var xhr = new XMLHttpRequest();
xhr.open("GET", "https://acme-staging.api.letsencrypt.org/directory");
xhr.onerror = function(){console.log("error");};
xhr.onload = function(){console.log("success");};
xhr.send();
========Firefox Result===========
> error
> Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://acme-staging.api.letsencrypt.org/directory. (Reason: CORS header 'Access-Control-Allow-Origin' does not match '*, *').
========Chrome Result===========
> XMLHttpRequest cannot load https://acme-staging.api.letsencrypt.org/directory. The 'Access-Control-Allow-Origin' header contains multiple values '*, *', but only one is allowed. Origin 'http://www.example.com' is therefore not allowed access.
> error
===================

Additionally, production is missing the
"Access-Control-Expose-Headers: Link, Replay-Nonce" header, which
prevents users from getting the replay nonce needed for ACME requests.

What's expected:
1. On staging, return only one ACAO header.
2. On production, add "Access-Control-Expose-Headers: Link,
Replay-Nonce" header.

Hope that helps clarify the problem.

-Daniel

[J.C. Jones]

I've alerted the ops team that Boulder's sending Access-Control-Allow-Origin on its own these days, so they'll fix the duplicate being appended upstream of the WFE.

I think the fix to Access-Control-Expose-Headers should be handled in Boulder, so I opened Issue #1147 in Boulder.

[J.C. Jones]

This issue should be resolved in production now, Daniel. Thanks for reporting!