oauth-server doesn't send CORS headers to requests with no `Origin` header

[rfk]

:pauljt and I discovered this while testing the proxy addon. In latest Nightly, CORS requests from a webextension do not include an Origin header. This breaks attempts by webextensions to talk to the oauth-server API, which gives a 404 to the CORS preflight request:

>>> # This works OK
>>> requests.request("OPTIONS", "https://oauth.accounts.firefox.com/v1/token", headers={
  "Origin": "https://example.com",
  "Access-Control-Request-Method": "POST"
})
...
<Response [200]>
>>>
>>> # This gives an error 
>>> requests.request("OPTIONS", "https://oauth.accounts.firefox.com/v1/token", headers={
    "Access-Control-Request-Method": "POST"
})
...
<Response [404]>                                                                                                                                                    >>>

I don't know enough about CORS to know whether this behaviour is expected or desired.

[rfk]

This appears to be deliberate behaviour from our web framework:

https://github.com/hapijs/hapi/blob/10d30d0b3c6b7a497a85f1be938cf7157f90566f/lib/cors.js#L115

[rfk]

We currently specify cors: true in the Hapi server definition. This will accept CORS requests from any origin, but try to send an Access-Control-Allow-Origin response header reflecting the incoming value from Origin, which obviously won't work if there is no Origin header.

IIUC from the code and docs, we could instead specify cors: { origin: 'ignore' } to accept requests from any origin without sending an Access-Control-Allow-Origin header. This should let the requests being sent from current Nightly through successfully.

However, I don't want to rush into that sort of a change without understanding why the current behaviour has changed in Nightly, and what other implications there might be of setting this option.

[rfk]

The culprit seems to be https://bugzilla.mozilla.org/show_bug.cgi?id=1405971 in which Origin headers were stripped from webextension requests to avoid fingerprinting.

[rfk]

Reading around a bit, I think setting cors: { origin: 'ignore' } will be an acceptable solution here.

It will cause us to return Access-Control-Allow-Origin: * in the response, telling the browser that any origin is allowed to make requests to this endpoint. Which is true.

That said, I expect we'll be far from the only site that expects CORS pre-flight requests to contain an Origin header, so I don't know if the current behaviour in nightly will stick.

[clouserw]

This got backed out of Nightly due to breaking lots of things. So, closing this, assuming that they are going to change the implementation.

[evilpie]

@rfk @clouserw Hey! Just as a heads-up, I tried landing this again.

I was mostly away for a few months so I kind of forgot about this. If we run into other problems with the patch, I am willing to try another approach, but it would be nice if you could first look into some solutions on your side.

Could you maybe just give the extension the proper host permissions?

[rfk]

Thanks for the heads-up. Setting cors: { origin: 'ignore' } rather than our current default of cors: { origin: ['*'] } should do the trick from FxA's perspective.

[rfk]

Could you maybe just give the extension the proper host permissions?

Aha, interesting. I don't believe we can just give the secure-proxy webextension host permissions here, but for complicated reasons.

The extension does in fact already request the <all_urls> permission, which IIUC should let it make requests to any domain without triggering any CORS checks.

But we have some measures inside Firefox that deliberately prevent webextensions from running on the accounts.firefox.com domain, even if they have the necessary permissions in their manifest.

So perhaps that special treatment of accounts.firefox.com is forcing the secure-proxy webextension to go through CORS even though it shouldn't have to. In conjunction with Bug 1405971 this generates an invalid CORS pre-flight request, which the FxA server quite rightly ignores due to the missing Origin header, which causes Firefox to fail the request.

This sounds similar to Bug 1450649, which notes that webextensions can't make requests to addons.mozilla.org, another special protected domain.

I think this argues in favour of us doing the above server-side change, since trying to fix it entirely on the client is going to be complicated.

[rfk]

Setting cors: { origin: 'ignore' }

sigh; it looks like this option is not supported in the older version of Hapi used by fxa-profile-server, and our previous attempt to update to newer Hapi got stuck on some unexpected failing tests.

Newer versions of the secure-proxy addon don't make requests to https://profile.accounts.firefox.com, but older versions do. It seems like that those versions will break as a result of the change in Bug 1405971, without a straightforward fix.