Sending Authorization Header on handshake?

[tonyghita]

Is it possible to specify an Authorization header on the socket connection handshake?

[brycekahle]

Currently no. See https://github.com/sockjs/sockjs-node#authorisation for more information.

[tonyghita]

That makes sense, thanks for the response.

[francoisledroff]

do you plan to support it in future release ?
It would be nice to be able to send oAuth token in the http header

[brycekahle]

@francoisledroff No. Read the link, it is a security issue to allow them because of the iframe transports. Authorization should occur over the SockJS channel.

[sdeleuze]

@brycekahle What about supporting it in a mode where you exclude IFrame based transports (with an explicit log message) ? Or the other way, you include the user provided Authorization header only if there is no IFrame based transport configured by the user.

Another strong argument in favor of supporting this is Basic Authentication. Based on my tests on Chrome, passing username and password in the URL, for example http://eric:azerty@mydomain.com is not supported for cross domain Ajax requests. The only solution seems to be creating yourself the Authorization header, so I would expect SockJS supporting this kind of configuration: var socket = new SockJS(url, null, {transports: ['xhr-streaming'], headers: {'Authorization': 'Basic ' + btoa(username + ":" + password)}});.

[brycekahle]

@sdeleuze That becomes a slippery slope. Once you start supporting that, then the server needs to have options for setting CORS headers.

What is your use case? Your example code would be incredibly insecure because the password is in plaintext, in the open.

[sdeleuze]

@brycekahle The basic authentication example was just coming from this SO question. I agree with you it is not very secured.

But I am a lot more concerned by the impossibility to use OAuth2 bearer token style security with SockJS, since it requires to customize the request headers. This kind of mechanism has been designed with cross domain in mind, being able to use it with SockJS makes sense IMO.

[IRus]

@sdeleuze 👍
If i set token in header, what wrong can be happen?
I use stateless session on server side.

[Mati20041]

For example with Spring Session you have option, to exchange session id with cookie, which automatically is send by browser with handshake or use header to send it (major thing if you deal with single page applications). I think there should be a way, to include some headers with handshake, even if they are not connected with authentication. Anyway session id is sent with every normal http request. Reconsider reopen this issue, because it may help many people.

[brycekahle]

@Mati20041 Session id is another form of authentication. The problem is a security one. If anyone can embed an iframe on the SockJS host domain, which automatically authenticates, and they can cause that iframe to send any message to your server, they now have full control. Anyone can secretly embed your SockJS iframe and do whatever they like with it.

This problem doesn't magically get solved. It would require fundamentally changing how SockJS works.

[Mati20041]

It is a problem which current Single Page Applications must face. Just like you can take the token, and use it outside the browser to use the API. Well, at least thank you for response.

[IRus]

@brycekahle but this is problem only for cookie based authentication, right?!