Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
#169: fix returning 'ws' for location even when the client connects v…
…ia 'wss'
- Loading branch information
ce88922
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If an external proxy which uncyphers SSL (say, stunnel) sits between the client and the server,
this.request.socket.encrypted
is false and the client won't be able to connect towss://*
. So the best is toor
both versions --this.request.socket.encrypted || origin && origin.substr(0, 6) === 'https:'
. Tested on my setup. Works. TIA.ce88922
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@dvv: If I'm not wrong, your suggestion would break https -> ws connections
ce88922
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe something like
this.request.socket.encrypted || this.request.headers['x-forwarded-proto'] === 'https'
would work. I'm not sure if stunnel passes such information, but in general... just maybe...See: https://github.com/jcoglan/faye/pull/40
ce88922
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, stunnel is TCP proxy, and in its pristine unpatched state knowing nothing of HTTP and its headers. Plus, externally set non-standard headers (
x-forwarded-proto
) are to be considered tainted, imho.I think it'd be better to extract current protocol determining logic out of
_onConnect
into a prototype method which can be overridden by authors.ce88922
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@guille: Please, consider applying https://gist.github.com/982523 -- this would retain the current behavior still allowing to override the logic. TIA
ce88922
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@dvv imo node needs a public method and/or prop for that as well, i dont think .encrypted is even documented so it's likely volatile (might be wrong)
ce88922
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Either an origin check or a way to force an override via config is needed. The current behavior is a regression for setups that are not doing the encryption inside the node.js process which is a valid deployment strategy.
Safari is the only browser we have come across so far that will not function if ws:// is used on a ssl wrapped conneciton.
ce88922
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@macros you're right, we need to add this option. I'll try to get this into the next minor release
ce88922
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any news on this?