Skip to content
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

'request.withCredentials = true' breaks CORS #1802

Closed
tomw1808 opened this issue Jul 27, 2018 · 28 comments
Closed

'request.withCredentials = true' breaks CORS #1802

tomw1808 opened this issue Jul 27, 2018 · 28 comments
Assignees
Labels
Bug Addressing a bug

Comments

@tomw1808
Copy link

The latest change in httpprovider breaks CORS with ganache and possibly other tools (for me at least), where the CORS-domain cannot be set explicitly.

Chrome comes up with the following error message: "Failed to load http://localhost:7545/: Response to preflight request doesn't pass access control check: The value of the 'Access-Control-Allow-Origin' header in the response must not be the wildcard '*' when the request's credentials mode is 'include'. Origin 'null' is therefore not allowed access. The credentials mode of requests initiated by the XMLHttpRequest is controlled by the withCredentials attribute."

Reproduce this issue by using the web3 0.20, e.g. "npm install web3@0.20" and then a simple index.html with the most simplistic content opening in Chrome:

<!doctype html>

<html>

<head>
  <script src="node_modules/web3/dist/web3.js" type="text/javascript"></script>
</head>

<body>

  <div>Here is some content.</div>


  <script>
    var web3;
    if (typeof web3 !== 'undefined') {
      web3 = new Web3(web3.currentProvider);
    } else {
      // set the provider you want from Web3.providers
      web3 = new Web3(new Web3.providers.HttpProvider("http://localhost:7545"));
    }

  </script>
</body>

</html>

Anything I can do on my side?

https://github.com/ethereum/web3.js/blob/b4c1542ddb5284267f6814ba0106bfbbc83fe166/lib/web3/httpprovider.js#L66

@nomoreboredom
Copy link

I am also experiencing this after migrating to version 35, following.

@H34D
Copy link

H34D commented Aug 2, 2018

i can confirm this, after downgrading to 0.20.6 it worked again.

@pierreneter
Copy link
Contributor

Related to #1803

@angelina999990
Copy link

Encountered the same issue which says 'The value of the 'Access-Control-Allow-Credentials must be true'. I'm using web3.js@0.20.7

@angelina999990
Copy link

after downgrading to 0.20.6 it worked again. It works as well

@nivida nivida added the 0.x.x label Aug 10, 2018
@nivida nivida self-assigned this Aug 10, 2018
@nivida nivida added Bug Addressing a bug and removed 0.x.x labels Aug 10, 2018
@tradzero
Copy link

i found safari will add user-agent to Access-Control-Request-Headers, and infura will reject this request. but i dont know how to remove that

@edwardfxiao
Copy link

edwardfxiao commented Aug 15, 2018

@tradzero downgrade to v1.0.0-beta.33 solved my problem

@levity
Copy link

levity commented Aug 30, 2018

For users of v1.0.0-beta, downgrading to v1.0.0-beta.34 will also work, because the issue was introduced after it, in this commit.

I had to downgrade in order to use HttpProvider with Infura. Probably the longer-term solution is to allow withCredentials to be turned off by an option in the constructor arguments.

levity added a commit to makerdao/governance-portal that referenced this issue Aug 30, 2018
@0xclem
Copy link

0xclem commented Sep 17, 2018

I can confirm that downgrading to v1.0.0-beta.34 fixes the issue. Both Safari and Firefox were impacted.

@karlphillip
Copy link

What is the correct command to downgrade to that specific version?

@0xclem
Copy link

0xclem commented Oct 4, 2018

@karlphillip something like yarn remove web3 && yarn add web3@1.0.0-beta.34 should work.

@karlphillip
Copy link

Thank you, ended up going with:
npm install web3@0.20.6 --save

@therightstuff
Copy link

#1956 resolves this by removing the credential requirement when there's no user / password supplied,

@frozeman @nivida this seems to be an issue for quite a lot of people, is there another way to work around this or do you have any comments for the PR?

thair116 added a commit to DoxaNetwork/32Daily that referenced this issue Nov 22, 2018
thair116 added a commit to DoxaNetwork/32Daily that referenced this issue Nov 22, 2018
@jamesmorgan
Copy link

Any ideas on how to solve this - I find it works in most browsers but safari?

@aratakokubun
Copy link

I have the same issue and can not resolve with Chrome, FireFox and Safari...

@todorone
Copy link

Unfortunately this is a blocking issue, so all versions above beta.34 are unavailable for React Native platform due to it's cookies headers resulting this error:

screen shot 2019-01-28 at 10 49 11 am

Can somebody proficient suggest any temporary workaround until this issue is resolved? Thanks.
@nivida @tomw1808

@barrard
Copy link

barrard commented Mar 21, 2019

Im getting this error also :(
Fetch API cannot load https://rinkeby.infura.io/v3/xxxxxxxx due to access control checks.

@nivida
Copy link
Contributor

nivida commented Mar 25, 2019

This got fixed with PR #2564 and will be released this week.

@nivida nivida closed this as completed Mar 25, 2019
@nivida nivida mentioned this issue Mar 28, 2019
12 tasks
@vanchinathans-git
Copy link

I can confirm that downgrading to v1.0.0-beta.34 fixes the issue. Both Safari and Firefox were impacted.

Thank you so much. It saved my day.

@glowkeeper
Copy link

glowkeeper commented Oct 15, 2019

I think I'm seeing the same issue on a MAC build of Clickz Latest, which is trying to run the following dat:

dat://795f83fa1356cd7d00e5cfe8f1a93f32c55127684c6fc4cb8ff89a32e000016b

That is a frontend to some contracts running on the Ethereum Rinkeby Test Network, so it relies on MetaMask to inject a web3.js instance that points to Rinkeby. Unfortunately, no matter what I do with MetaMask, my app' thinks it's on the Ropsten network, and I get these errors:

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at http://127.0.0.1:8545/. (Reason: CORS request did not succeed).

I'm assuming that the reference to http://127.0.0.1:8545/ comes from web3.js, since it is not mentioned anywhere else in my code.

Interestingly, the very same dat works seamlessly on vanilla Firefox with the dat P2P protocol extension installed.

Meanwhile, what to do concerning that error using Clickz Latest? I've seen some possibilities involving XMLHttpRequest, but I can't find any docs as to how to use that when setting my web3 provider. Would it help?

@nivida
Copy link
Contributor

nivida commented Oct 15, 2019

@glowkeeper This got fixed with #3112 and will be released with 1.2.2.

@glowkeeper
Copy link

glowkeeper commented Oct 15, 2019

Awesome! When is 1.2.2 due for release?

@0xZick
Copy link

0xZick commented Oct 18, 2019

@nivida When is 1.2.2 due for release ?)

@glowkeeper
Copy link

@nivida - I appreciate you're probably busy, but I'm trying to work out project plans for some of my dApps, and that 1.2.2 upgrade has become an important ingredient of those plans. Any news on release dates?

@nivida
Copy link
Contributor

nivida commented Oct 19, 2019

The release is planned for Monday. I will do the last tests and improvements over the weekend and will release it in the late afternoon on Monday (CEST)

@glowkeeper
Copy link

Brilliant - thanks, @nivida

@glowkeeper
Copy link

Problems?

@glowkeeper
Copy link

Oooo - just seen the new version - awesome - thanks @nivida!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug Addressing a bug
Projects
None yet
Development

No branches or pull requests