Skip to content
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

extraHeader ignored in browser #976

Closed
fullstackwebdev opened this issue Jun 27, 2016 · 12 comments
Closed

extraHeader ignored in browser #976

fullstackwebdev opened this issue Jun 27, 2016 · 12 comments

Comments

@fullstackwebdev
Copy link

This line, seems to detect if we are in a node.js environment:

var freeGlobal = typeof global == 'object' && global;

However, I am trying to set in the browser (Angular) :
extraHeaders : { Authorization : 'Bearer xxxx' }

for JWT authentication to my REST service, hapi-io, which supports token authentication for websockets.

How else can I set a header or accomplish the same thing?

If I comment code around 2177, it doesn't not send the header.

Thanks

@fullstackwebdev
Copy link
Author

Note for people who found this via google in the future:

As a work around for now, I am passing the token in the query ( io.connect(undefined, { query : "token="+auth.getToken()} );

Then, on my server which is Hapi, I use hapi-auth-jwt2 which has a authentication strategy for tokens that has query parameter /?token= built in and enabled by default. Only use it with SSL.

However I would like to use extraHeaders if possible. Thanks!

@gaastonsr
Copy link

Thanks @fullstackwebdev. I'm having trouble to find the documentation of the options.

@brettmc
Copy link

brettmc commented Jul 28, 2016

@fullstackwebdev I've been fighting with extraHeaders in an angular app all day. I too think extraHeaders during the initial handshake would be the best way.

I just successfully implemented this concept which seems like a more elegant solution than passing query parameters. I think it should be safe if you are using SSL/wss.

Basically, you let the socket connect, but then make the client pass their token in an 'authorize' message.
Something like this (server):

io.on('connection', function (socket) {
    socket.authorized = false;
    socket.emit('connected', {connected: true, authorized: false});
    setTimeout(function(){
        if(!socket.authorized) {
            socket.disconnect(true);
    }, 1000; //1 second to authorize or kill the socket
    socket.on('authorize', function(data) {
        //validate token, set socket.authorized = true, socket.username etc

and this (client):

var socket = io(host);
socket.on('connected' function (data) {
    console.log("connected but not authorized");
    socket.emit('authorize', {token: "oauth/JWT token goes here";
});
socket.on('authorized', function (data) {
    console.log("authorized");
});

@gaastonsr
Copy link

gaastonsr commented Jul 28, 2016

They have a point. If I remember correctly since sending headers is not the in the official spec of Websocket is not something they want to support.

The way I fixed this in my case is by sending the value I want to send through a cookie. But query params works too.

@darrachequesne
Copy link
Member

=> socketio/engine.io-client#519.

@gaastonsr
Copy link

So this is supported now?

@vitriol
Copy link

vitriol commented Jan 18, 2017

So it seems like this was added to master. Does anyone know if other clients (android,ios) will implement this soon ?

@mikermcneil
Copy link

@vitriol @gaastonsr this is related to socketio/engine.io-client#554

@darrachequesne
Copy link
Member

@fullstackwebdev since 2.0.0, you can now provide an extraHeaders object:

const socket = io({
  transportOptions: {
    polling: {
      extraHeaders: {
        'x-clientid': 'abc'
      }
    }
  }
});

Added to the documentation here.

@acarstoiu
Copy link

This issue should be reopened for the websocket transport.
In the socket.io API documentation you've placed a link to the WebSocket RFC, chapter 4, but if you keep reading in there you'll encounter this paragraph:

 12.  The request MAY include any other header fields, for example,
        cookies [RFC6265] and/or authentication-related header fields
        such as the |Authorization| header field [RFC2616], which are
        processed according to documents that define them.

So, there's no rule against setting other headers from the browser, when establishing WebSocket connections - quite the contrary. By coincidence or not, I landed here precisely because of an authentication problem.

The engine.io-client's documentation should be ammended, too.

@acarstoiu
Copy link

I got it, you're missing a proper API in browser. Damn.

@onbetelgeuse
Copy link

From client side. You must to inverse your transport mode like that : ['polling', 'websocket'] and set withCredentials: true to activate credentials cookies and extraheaders

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants