CORS Errors after updating to 2.2.0

[sjones6]

You want to:

• report a bug
• request a feature

Current behaviour

Getting lots of CORS errors after the latest update.

Steps to reproduce (if the current behaviour is a bug)

Repo. See README for instructions.

Expected behaviour

No CORS errors.

Setup

• OS: Mac
• browser: Chrome 70
• socket.io version: 2.2.0

Other information (e.g. stacktraces, related issues, suggestions how to fix)

@davericher made a comment here indicating this. Perhaps he has more details.

[Bramzor]

+1 Started to fail since I downloaded the packages again.

[Bramzor]

Workaround: npm install socket.io@2.1.1

[xaviergonz]

The funny thing is that I'm using a custom origins callback and it returns "*" as allowed origin instead of the actual origin passed from the client when the callback is called with success set to true.
On 2.1 it used to return the origin header passed from the client.

[darrachequesne]

Hmm.. I don't see anything related in the changelog... It may be the update of the ws package.

Is anyone able to reproduce the issue?

[neemah]

Yes. You need to have socket server on separate domain.

[sjones6]

@darrachequesne : I updated my description with a link to repo where you can reproduce the issue. Instructions are in the README at the repo.

[sjones6]

Another way to solve: fill in the origin property in your socketio server config:

const Server = require('socket.io');
const io = new Server({
  origins: 'http://your-cors-url' // i believe can also be an array of urls, defaults to '*'
});

You should see this show up in the response headers for the handshake request in your network tab:

The browser should stop complaining about the CORS violation then.

[sjones6]

@darrachequesne It seems like if you comment out these lines in engine.io-client:

if ('withCredentials' in xhr) {
  xhr.withCredentials = true;
}

then the requests succeed.

So maybe, in v <2.2.0, somehow 'withCredentials' in xhr === false?

[darrachequesne]

@sjones6 thanks for the repo. What I don't understand is that your example is a basic CORS situation, where the client is served from a location (localhost:3001) different from the server (localhost:3000). That shouldn't work in the previous versions either, and is solved with the origins parameter, as you pointed out.

[xaviergonz]

I think with credentials was always set to true.

The problem is that allow origins * is not allowed when with credentials is set to true. Previous versions would use the client origin (or referer if missing) header when an origin was valid, but the new version just uses "*", and therefore the browser complains.

https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS/Errors/CORSNotSupportingCredentials

[darrachequesne]

@flenter could it be related to socketio/engine.io#511?

[xaviergonz]

Another option is of course to set with credentials to false, but that'd mean that the socket io server does not care about getting / setting any cookies. Not sure if that's the case with socket io

[neemah]

https://github.com/socketio/engine.io/pull/511/files#diff-c945a46d13b34fcaff544d966cffcabaL259

[xaviergonz]

That pr could have added a way to set the header to the client request origin header. Maybe a good place to do this is that when using origins with a callback and the callback is called with success true the Allow-origins would be set to the origin that was passed to the callback.

Either way, after that PR this is a breaking change though I guess?

As it is right now I see no way to support all origins when with credentials is set to true