CORS Error on /authenticate/api

[mattpocock]

Access to fetch at 'https://devapi.currencycloud.com/v2/authenticate/api' from origin 'http://localhost:3000' has been blocked by CORS policy: The 'Access-Control-Allow-Origin' header contains the invalid value ''. Have the server send the header with a valid value, or, if an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.

Calling authentication.login gives us the error above. I can't immediately see in the code how to set the request's mode to be no-cors.

This is an irregular bug which could be being caused at the TCC API end - often we can access it without CORS errors at all, but this downtime is obviously a blocker.

[jonathancouchman]

@mattpocock we strengthened our security measure on the dev environment and this may have caused the issue you are seeing. We have made some further changes, please let me know if the issue still persists

[mattpocock]

@jonathancouchman Looking good now - thanks for getting in touch so quickly.

[mattpocock]

Seeing something similar now on Safari, when trying to login in the dev environment:

Chrome is working fine, this is Safari-only.

[r-moore]

Following up on support case 8827 here....

if you make a call to authenticate, you will see the response has the header Access-Control-Allow-Origin : * so CORS is currently enabled, as it was previously, so I am not sure where it could be on our side that is breaking their code. If they can give you more context, maybe we could try and reproduce using safari it is possibly a bug in the SDK

It's the Access-Control-Allow-Headers check that seems to be violated. I am still seeing it today in Safari, but the same call to authenticate via the SDK works in Chrome.

Here's a trace of the network requests from the developer tools:

Chrome

POST /v2/authenticate/api
accept: */*
accept-encoding: gzip, deflate, br
accept-language: en-GB,en-US;q=0.9,en;q=0.8
content-length: 108
content-type: application/x-www-form-urlencoded
origin: https://staging.payewg.yozobi.com
referer: https://staging.payewg.yozobi.com/currency/balances
sec-fetch-mode: cors
sec-fetch-site: cross-site
user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3936.0 Safari/537.36

Safari

POST /v2/authenticate/api
User-Agent: CurrencyCloudSDK/2.0 NodeJS/3.4.0
Content-Type: application/x-www-form-urlencoded
Origin: https://staging.payewg.yozobi.com
Referer: https://staging.payewg.yozobi.com/currency/balances
Accept: */*

It's weird because in line 23 of currencycloud-js/lib/client.js it looks like the user-agent header should be what Safari is sending (CurrencyCloudSDK/2.0).

[jonathancouchman]

Can you confirm that this was working previously in Safari? Do you have Headers in the response that you could share?

[r-moore]

I am sure the SDK has worked previously in Safari but it currently seems to be consistently broken for the last few weeks. Unfortunately I can't actually see any response in the Safari dev tools.

The good news is that I have managed to fix this issue in a fork of the currencycloud-js SDK by removing the User-Agent headers in client.js (see https://github.com/CurrencyCloud/currencycloud-js/commit/e65596906f0094f04d157f8410b6b9a8d9591c33#diff-50cfa59973c04321b5da0c6da0fdf4fe). It seems to fix the issue for me in Safari and it still works in the Chrome & Firefox (I have only tested latest versions).

If there is nothing else to consider then please do let me know if you want a PR.

[r-moore]

Just to add I see the same errors in Firefox too:

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://devapi.currencycloud.com/v2/authenticate/api. (Reason: header ‘user-agent’ is not allowed according to header ‘Access-Control-Allow-Headers’ from CORS preflight response).

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://devapi.currencycloud.com/v2/authenticate/api. (Reason: CORS request did not succeed).

[r-moore]

Here are the response headers from the API responding to a OPTIONS request from Firefox:

HTTP/2 200 OK
date: Thu, 28 May 2020 21:25:31 GMT
content-type: application/octet-stream
set-cookie: __cfduid=d48744ce5283cef4e4ce893eec66b52661590701131; expires=Sat, 27-Jun-20 21:25:31 GMT; path=/; domain=.currencycloud.com; HttpOnly; SameSite=Lax
set-cookie: AWSALB=ZBUB/jHFWi2POxBPi4tInGe9wdEyUcgaxUg11Fjm/xvVo0adSNUVlzI8kOxMrK99+UtF+29j6lrTicZb2WI6bx7xoyCj2ZP/LdVSfRz02EAsYq6zAMGpW3qZ2+Zp; Expires=Thu, 04 Jun 2020 21:25:31 GMT; Path=/
set-cookie: AWSALBCORS=ZBUB/jHFWi2POxBPi4tInGe9wdEyUcgaxUg11Fjm/xvVo0adSNUVlzI8kOxMrK99+UtF+29j6lrTicZb2WI6bx7xoyCj2ZP/LdVSfRz02EAsYq6zAMGpW3qZ2+Zp; Expires=Thu, 04 Jun 2020 21:25:31 GMT; Path=/; SameSite=None; Secure
referer: http://localhost:3000/currency/balances
access-control-allow-origin: *
access-control-allow-methods: POST
origin: http://localhost:3000
cdn-loop: cloudflare
cf-connecting-ip: 62.68.161.139
accept-language: en-US,en;q=0.5
cf-ipcountry: JE
x-forwarded-proto: https
cf-visitor: {"scheme":"https"}
dnt: 1
access-control-request-method: POST
x-forwarded-port: 443
access-control-allow-headers: authorization,Access-Control-Allow-Origin,Content-Type,SOAPAction,X-Auth-Token,Origin,Authority
x-amzn-trace-id: Root=1-5ed02c4b-f05625ea252d7a98278899be
accept: */*
wso2_am_api_default_version: true
access-control-request-headers: user-agent
x-forwarded-for: 62.68.161.139, 141.101.69.236
cf-request-id: 02fec61d0000000863a8bf0200000001
user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:77.0) Gecko/20100101 Firefox/77.0
cf-cache-status: DYNAMIC
expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
strict-transport-security: max-age=2592000; includeSubDomains
server: cloudflare
cf-ray: 59ab0c74cd7c0863-CDG
X-Firefox-Spdy: h2

It's this particular one (access-control-allow-headers) that seems to be causing problems, it is missing 'User-Agent'.

Perhaps instead of merging my change to the SDK a better way to fix this issue is to make the API respond with: access-control-allow-headers: authorization,Access-Control-Allow-Origin,Content-Type,SOAPAction,X-Auth-Token,Origin,Authority,User-Agent

[jonathancouchman]

@r-moore thanks for useful input on this issue, we will investigate further and get back to you ASAP

[jonathancouchman]

As suggested, we will add User-Agent to access-control-allow-headers in responses

[jonathancouchman]

All responses now contain the User-Agent as part of the Access-Control-Allow-Headers. Can you confirm this resolves the issue?

[r-moore]

Yes I can see that now, thanks for fixing 🎉