CLIENT_GATEWAY_NETWORK due to CORS error when using Fiddler

[simeyla]

General information

• SDK version: 3.76.0
• Environment: Production
• Browser and OS: Chrome + Fiddler on Windows

Issue description

Developers often have tools such as Fiddler open for debugging. For the most part other websites will continue to work as normal, but it seems that CORS errors can occur when trying to make calls to graphql endpoints on payments.braintree-api.com and api.braintreegateway.com if Fiddler is open.

I do want to make it clear that I understand development environments are going to have side-effects on everyday web browsing, but clearly people make purchases on their work computers with developer tools open. Other developers are my customers and this is very hard to diagnose if you can't see a dev tool trace.

This issue does not occur on the hosted fields sandbox demo, but is easily reproduced in production by opening Fiddler and trying to create a client. I randomly picked Casper from your featured merchants to demonstrate but these are the same errors I got on my own website:

 {
   code: "CLIENT_GATEWAY_NETWORK"
   details:
   originalError: "error"
   message: "Cannot contact the gateway at this time."
   name: "BraintreeError"
   type: "NETWORK"
}

This error is frustratingly not handled by most companies, leaving a 'dead' unclickable credit card form with no feedback.

I'm not expecting a magic solution to this issue, but opened it in the hope of exploring some of the following:

1) Make sure anyone experiencing a CLIENT_GATEWAY_NETWORK error understands that simply having Fiddler open can be a cause!

2) Suggest that if hosted fields fails to initialize because of this error that maybe a subsequent click on the text box should show a default inline error message or popup suggesting reload / contact us.

2) Suggest a different error message such as CLIENT_CORS_ERROR that could be raised if CORS could be determined to be the underlying cause.

• Unfortunately this may not be possible. I tried putting some breakpoints in client.js but the error itself never surfaced via the XmlHttpRequest call (in the ReadyStateChanged handler). I even manually added an additional onerror handler and couldn't see it. The error details do get printed to the console, but as shown above originalError == 'error' and nothing useful to distinguish the reason.

3) Point out that the http status code returned from the CORS problem is 0 but client.js converts this to a 500 error with status || 500 when it isn't really a true 500 error.

4) Confirm that there's no other way your server can be configured to avoid this. I assume it's configured very deliberately for security reasons, but I never really understand CORS beyond the minimum I need to know!

5) See if anyone has recommendations for how to configure Fiddler to avoid this. I've found some possible solutions but they involve modifying every request with a filter.

6) Recommend all developers test for this, hide the hosted fields and show an error message - this is what I'm now doing:

[crookedneighbor]

I'm talking to our networking team about this to see if there's anything specific to our setup that would cause this.

[simeyla]

@crookedneighbor sorry! It looks like I did in fact have some custom rule in Fiddler that was affecting this - that would be rare for anyone else to have.

[hollabaq86]

@simeyla it's all good! We'd rather folks come to us with issues than stay quiet 😄

[WellingtonBraga]

Hi, I am investigating a sudden increase on the number of this error occurrences in our app. It seems so far that nothing on our end would cause such increasing. It seems to me at this point that this is most likely related to customer network issues then something else. Sorry, but just to clarify, In which cases this error is commonly noticed? If here is not the best place to ask, please point me the correct place.

Thanks.