How to pass custom header (auth cookie) to the websocket creation?

[bzroom]

My authentication requires a certain header. This seems to work fine with http but with websocket it's not inheriting the headerjar. In socket.io this seems to happen automatically. Is it advisable to use socket.io if we need custom headers? Would it be worth while to implement a socket.io subscriber type in order to get the headers?

By the way. Thank you!

[bzroom]

I lied. It does inherit the session cookies, BUT, only if the hostnames from the session and the websocket match exactly. This was my mistake. My apologies.

[The-Don-Himself]

I think this issue should be reopened, it would be nice to be able to pass custom headers through the options passed to NchanSubscriber.

I have a misbehaving frontend that hogs the actual token via local storage because, rightly so, not every request to the backend should include oauth tokens something cookies do by default. I currently hack this using regex in Nginx's map but having this feature natively available can avoid that and add flexibility.

[slact]

The issue here is that custom headers can't be passed via the native EventSource and Websocket objects, which are used inside NchanSubscriber. It's only possible for long-polling, which uses XMLHTTPRequest. So it's not something that can be implemented for even a majority of the available transports.

Adding headers would either force NchanSubscriber to use long-polling, or error out if websocket/eventsource are the only available choices. I'm not sure this is worth doing.

What do you think?

[The-Don-Himself]

I have researched a bit more on this and you are definitely correct. Custom headers are far more complicated than first seems because of a lack of native browser support. I think for now people should hack it using query params or similar. But once the Nchan community gets larger and larger, as I'm sure it will, this should probably be on the road map some time if use cases grow.

So this issue should remain closed for now.

[slact]

Unfortunately, this is an issue for browser vendors and the W3C spec writers to sort out. If you need to pass custom data, I recommend doing it with query-string parameters. It's actually how I'm passing the last-message-id for resuming interrupted connections.

Still, I'll keep this in mind. There's certainly a use case for passing custom parameters for each transport type, including custom headers for long-polling.

[The-Don-Himself]

Sorry for still dwelling on this, but I have been digging around for some acceptable hacks and came across modifying one header, namely Sec-WebSocket-Protocol.

I currently see it's set to :--

ws+meta.nchan

I think if we could be allowed to customize this so as to add say a Bearer Token or a json payload that can be converted to objects on the Nchan nginx server, that would be great. Thoughts @slact

RE: http://stackoverflow.com/questions/22383089/is-it-possible-to-use-bearer-authentication-for-websocket-upgrade-requests

[arnuschky]

That would be awesome, yes. (I just encountered the same problem with bearer tokens, I guess I'll hack it up by using basic auth.)

[slact]

For OAuth stuff, why not just pass the bearer token in the url? http://self-issued.info/docs/draft-ietf-oauth-v2-bearer.html#query-param