Open maxwellhaydn opened 6 years ago
@maxwellhaydn thanks for reporting this. For some reason I cannot reproduce the issue (maybe a settings difference). Also the docker image doesn't seem to be affected.
That said, the third argument passed to the cb
should in fact be a string; so I agree with your suggestion. We need to account for the possibility that the developer might pass back a string to the next
function; so maybe it should be:
var errorReason = typeof err === 'string' ? err : err.message;
cb(false, 401, errorReason);
Also, we need to do the same with the other cb(...)
below.
Ah yes, I like your solution of accepting a string or an Error object better.
@maxwellhaydn Ok, I published the patch in socketcluster-server@14.3.2
.
@jondubois Great! Thanks for the quick turnaround!
According to the documentation for MIDDLEWARE_HANDSHAKE_WS, you can pass an error object to
next()
to block a connection before the underlying WebSocket is created. However, doing so causes the SocketCluster worker to crash:Here's the worker.js that generated the above output:
This happens because the WebSocket backend's
verifyClient
callback expects the third argument to be a string, but SocketCluster is passing the error object. See the docs for wsverifyClient
:It can be fixed in socketcluster-server as follows (although it would be better to check whether
err
is actually an object with amessage
property):