Socket.io-client: permitir acesso a cabeçalhos de handshake

Criado em 14 mar. 2014  ·  19Comentários  ·  Fonte: socketio/socket.io-client

Ao estabelecer a conexão, posso 'acessar' a string de consulta via io.connect(url, {query:'key=value'})

Eu esperava ser capaz de fazer algo semelhante com os cabeçalhos.

Eu gostaria de usar isso para construir webapi, com autenticação de token.

Comentários muito úteis

+1 alguma atualização sobre isso?

Todos 19 comentários

Gostaria de ter isso também.

Acho que seria melhor dizer para 'definir' os cabeçalhos ao fazer a solicitação.

O problema de esperar mudanças de cabeçalho é que certos transportes não as permitem:

  • WebSocket não permite cabeçalhos personalizados
  • JSONP Polling (também conhecido <script> ) não os permite

A única condição que nos permitiria definir cabeçalhos específicos é forçar o socket.io a usar apenas XHR Polling

Eu estava esperando algo semelhante para poder autenticar os clientes. Enviar um token de autorização (ou uma senha) na string de consulta não é uma boa ideia.

Eu criei um módulo para enviar credenciais no corpo: https://github.com/invisiblejs/socketio-auth

@rauchg você pode explicar melhor, a documentação em https://github.com/Automattic/socket.io/wiki/authorizing#handshaking diz:

The handshake is initiated with either an XHR request or a JSONP request

Porque:

Users might want to authorize the clients based on information from the headers or IP address

Desde a:

Not all transports sends headers when they attempt to establish a real time connection with the server

Portanto, isso não indica que ele ainda pode estabelecer uma conexão WS, mesmo que o handshake estivesse em XHR e, portanto, usar cabeçalhos de solicitação para autorização é bom?

Parece que você tinha código para isso em um estágio https://github.com/Automattic/socket.io-client/issues/344#issuecomment -9424237

Então, acho que houve problemas, por isso nunca chegou ao repositório principal, além dos cookies, que parecem ter sido removidos. Nesse caso, seria bom atualizar a documentação do servidor, que é um pouco enganosa http://socket.io/docs/server-api/#namespace #use%28fn:function%29:namespace

var io = require('socket.io')();
io.use(function(socket, next){
  if (socket.request.headers.cookie) return next();
  next(new Error('Authentication error'));
});

pois indica que cookies (ou seja, cabeçalhos) podem ser usados ​​para autenticação. E adicione um substituto ao documento wiki de autenticação obsoleto no site principal com exemplos de autenticação e menção de problemas com outras abordagens, pois tenho certeza de que é um cenário comum.

+1 para alguma resolução para isso. Os documentos e exemplos consumiram meu tempo, pois eu esperava um melhor acesso à configuração de cabeçalhos para autenticação de token também.

+1. Há uma versão futura do cliente engine.io que permite o acesso aos cabeçalhos, o que deve facilitar a resolução desse problema.
https://github.com/socketio/engine.io-client/pull/379

Isso também está disponível na biblioteca JS do cliente? Além disso, ele realmente entrou? Vejo que está mesclado, mas não acho que esteja operacional, pode estar errado

+1. Eu me deparei com uma situação semelhante em que preciso autenticar clientes do navegador. socket.io-client parece não permitir isso.

+1 alguma atualização sobre isso?

Alguma atualização sobre isso?

Alguma atualização sobre isso?

Como 2.0.0 , agora você pode fornecer um objeto extraHeaders :

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

Adicionado à documentação aqui .

Como 2.0.0 , agora você pode fornecer um objeto extraHeaders :

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

Adicionado à documentação aqui .

Estou recebendo o seguinte erro CORS com isso, embora esteja usando cors com express :

A resposta à solicitação de comprovação não passa na verificação de controle de acesso: não tem status HTTP ok.

@4nubhav você tem que passar uma função handlePreflightRequest como esta:

    handlePreflightRequest: (request, response) => {
        const headers = { ... };
        response.writeHead(200, headers);
        response.end();
    }

Como 2.0.0 , agora você pode fornecer um objeto extraHeaders :

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

Adicionado à documentação aqui .

Eu uso .of("/path") no servidor Socket, então o que eu faço onde declaro URL.

@4nubhav você deve permitir esse cabeçalho com handlePreflightRequest no lado do servidor.

const options = {
    handlePreflightRequest: (req, res) => {
        res.writeHead(200, {
            'Access-Control-Allow-Headers': 'x-clientid', // <<< this
        });
        res.end();
     },
};
const io = require('socket.io')(server, options);

Atualização: no Socket.IO v3, o transportOptions não é mais necessário, você pode simplesmente usar:

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

Documentação para CORS:

Esta página foi útil?
0 / 5 - 0 avaliações