-
-
Notifications
You must be signed in to change notification settings - Fork 1.9k
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
Default provider has CORS Problem in Firefox and Safari #858
Comments
I use Safari almost exclusively, and I also just tried in Firefox on my local computer and both work fine. It may be something else with your configuration. Can you provide more background? |
e.g. in both Safari and Firefox: const provider = ethers.getDefaultProvider();
provider.getBalance("ricmoo.firefly.eth").then((balance) => {
console.log(balance.toString());
});
// "955864037352077165" |
@ricmoo That exact code fails in both Firefox and Safari for me but succeeds without issue in Chrome. I don't know what is different. Browser version? ethers.js version? I provided all my versions above, do yours match? Thing is, our product was failing for our users when we used code like what you provided...so I had to work around with axios. So this isn't just my environment, it would be a handful of other users as well. My current solution uses a custom provider that extends JsonRpcProvider and overrides its 'send' function to use axios. That works perfectly. I don't know what the difference is between what ethers.js is doing and what axios might be doing but there is clearly a difference somewhere. |
Safari 13.1
Firefox 72
Can you provider more context? Like a screen shot of the browser, with the errors in the console and the address bar? What network are you connecting to? |
Not sure what other context you need...I literally used your example and I get errors. I think I've given plenty of info on what the issue is. If you monitor your network while calling your code snippet in Firefox/Safari, what Access-Control headers are being sent to Infura? If it includes user-agent, it should fail because infura doesn't allow that header for CORS requests. If it doesn't send that header, then somehow your browser is configured differently. If it does and still doesn't get CORS error, I'm at a loss on why Infura would give you a different response. |
I mean, I need at least enough context in order to reproduce it. :) Can you try this link? It works for me in both Safari (a compatible version to yours) and Firefox (an older version than yours). Can you take a screen shot of the browser with the error console open and the browser bar visible? Do you perhaps have any plug-ins that could be messing with things? Even if INFURA was not working, the code should work fine, since it would would hit Etherscan... |
Any news? I may close this tomorrow if I can't reproduce it. |
I had the exact same problem about an year ago but with I'm not sure if my problem was solved because I moved to |
I'm going to close this now, but if you can help reproduce it, please let me know and re-open... |
We're experiencing the same. @ricmoo, your example works because
|
I never responded above because your code snippet worked in the simplest case so I assumed it must have been my build environment. But since others chimed in, I know it's not just me. I'm using default provider but for a specific network (homestead for example) and it fails. Does that help? I'm using within a create-react-app (CRA) so not sure if the build process for CRA conflicts with something to create this weird scenario. |
There is no xhr used in ethers, so it sounds like your bundler is pulling in some shim for fetch? Actually, looking at your code, you are targeting an ancient version of ethers that was uploaded as a one-time demo (where did you get that link?). Can you try using the version linked to in the readme? |
I got it from here #858 (comment). I opened your link, took the source code and modified it to cause the error condition. I figured it'd be helpful if I based my example on the same test code you provided. Sorry if that was a bad call! The version we're using in the context where this issue arose is Now, I think your question about this being caused by bundlers might be pointing in the right direction. Here's why I think that may be the case: Guided by @mdcoon's hint about overriding It certainly doesn't look like the problem is caused by |
@mverzilli would you please share the code of your extended JsonRpcProvider? That would be so much appreciated. |
Sure, keep in mind it's just a copy of the original code, just vendored into your project to remove any bundling weirdness. It's probably not even the right solution, it's more of a hack. See the code below, code is provided as is with no warranties whatsoever :).
|
@mverzilli thanks a lot :) ! Understandable. `
|
Not sure if that's the issue, but keep in mind I was using this on Ethers 4, not Ethers 5, which based on your stack trace seems to be the version you're on |
Correct, I was using v5. I tried with ethers 4.0.48 and I got the error down below 😔
|
Fixed! The problem was that the client sent over a HTTP POST parameter value "undefined" instead of the address of user's crypto wallet. Our custom Smart Contract method got this value as method parameter. For some reason the CORS error happened when we called this method with value "undefined". |
When using default provider in Firefox or Safari to do something as simple as get a wallet balance, there are CORS errors due to unacceptable 'user-agent' header being passed from these browsers. Chrome does not pass this header so it works without issue.
I confirmed that if I use axios to manually construct the RPC call and override headers to only include Content-Type, the request goes through without issue. I see that it's possible for providers to override default options to ethersjs web connector. The fix might be as simple as supplying default "Content-Type" header if there are no other headers offered by the provider impl. Basically something needs to replace the browser default headers.
Using ethers version: 4.0.47
Firefox version: 76.0.1 for Mac
Safari version: 13.0.3
The text was updated successfully, but these errors were encountered: