-
Notifications
You must be signed in to change notification settings - Fork 571
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
Engine.io to not set CORS headers on error response #449
Comments
How about adding a new error |
I believe that would require to expose error codes to the outside i.e. the
or maybe (imho better) add separate callback function for handling 'allowance' to the |
You mean, something like the following? Server.prototype.verify = function (req, upgrade, fn) {
(...)
} else {
// handshake is GET only
if ('GET' !== req.method) return fn(Server.errors.BAD_HANDSHAKE_METHOD, false);
if (!this.allowRequest) return fn(null, true);
return this.allowRequest(req, function (err, success) {
fn(err ? Server.errors.REQUEST_DENIED : null, success);
});
); |
Yeap. That would do the trick. |
It's now possible to specify an origins value (default value is '*') when initialising the engine. This value will be returned as the Access-Control-Allow-Origin value. Related: #449
I have an issue similar to #331 but related to the error situations which are eventually handled by the sendErrorMessage (https://github.com/socketio/engine.io/blob/master/lib/server.js#L236)
I have socket.io configured to allow only certain origins and in case of origin that is not passing validation I can see verify method failing (https://github.com/socketio/engine.io/blob/master/lib/server.js#L159) due to not allowed request. Unfortunately the error response generated by sendErrorMessage is having that unallowed origin set in Access-Control-Allow-Origin header which is
a) a bit confusing as my response about not allowed origin at the same time claims to allow it via Access-Control-Allow-Origin header
b) such responses are picked up by the security scans
Is there any reason sendErrorMessage explicitly sets the CORS headers? Could we add some way to somehow control their presence?
The text was updated successfully, but these errors were encountered: