Socket.io-client: permitir el acceso a los encabezados de protocolo de enlace

Creado en 14 mar. 2014  ·  19Comentarios  ·  Fuente: socketio/socket.io-client

Al establecer la conexión, puedo 'acceder' a la cadena de consulta a través de io.connect(url, {consulta:'clave=valor'})

Esperaba poder hacer algo similar con los encabezados.

Me gustaría usar esto para construir webapi, con autenticación de token.

Comentario más útil

+1 alguna actualización sobre esto?

Todos 19 comentarios

Me gustaría tener esto también.

Creo que sería mejor decir "establecer" los encabezados al realizar la solicitud.

El problema de esperar cambios de encabezado es que ciertos transportes no los permiten:

  • WebSocket no permite encabezados personalizados
  • JSONP Polling (también conocido como <script> ) no los permite

La única condición que nos permitiría establecer encabezados específicos es obligar a socket.io a usar solo XHR Polling

Esperaba algo similar para poder autenticar a los clientes. Enviar un token de autorización (o una contraseña) en la cadena de consulta no es una buena idea.

Creé un módulo para enviar credenciales en el cuerpo: https://github.com/invisiblejs/socketio-auth

@rauchg , ¿puede explicar eso con más detalle? La documentación en https://github.com/Automattic/socket.io/wiki/authorizing#handshaking dice:

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

Ya que:

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

Entonces, ¿no indica esto que aún puede establecer una conexión WS a pesar de que el protocolo de enlace estaba en XHR y, por lo tanto, está bien usar encabezados de solicitud para autorización?

Parece que tenía código para ello en una etapa https://github.com/Automattic/socket.io-client/issues/344#issuecomment -9424237

Así que supongo que hubo problemas, por lo que nunca llegó al repositorio principal, aparte de las cookies, que parece que se han eliminado desde entonces. En cuyo caso, sería bueno actualizar la documentación del servidor, que es un poco engañosa 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'));
});

como indica, las cookies (es decir, los encabezados) se pueden usar para la autenticación. Y agregue un reemplazo al documento wiki de autenticación obsoleto en el sitio principal con ejemplos de autenticación y mención de problemas con otros enfoques, ya que estoy seguro de que es un escenario común.

+1 para alguna resolución a esto. Los documentos y ejemplos consumieron mi tiempo, ya que esperaba un mejor acceso a la configuración de encabezados para la autenticación de tokens también.

+1. Hay una próxima versión del cliente engine.io que permite el acceso a los encabezados, lo que debería facilitar la resolución de este problema.
https://github.com/socketio/engine.io-client/pull/379

¿También está disponible en la biblioteca JS del cliente? Además, ¿alguna vez entró? Veo que esta fusionado pero no creo que este operativo, puede estar mal

+1. Me encontré con una situación similar en la que necesito autenticar a los clientes del navegador. socket.io-client no parece permitirlo.

+1 alguna actualización sobre esto?

¿Alguna actualización sobre esto?

¿Alguna actualización sobre esto?

Desde 2.0.0 , ahora puede proporcionar un objeto extraHeaders :

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

Añadido a la documentación aquí .

Desde 2.0.0 , ahora puede proporcionar un objeto extraHeaders :

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

Añadido a la documentación aquí .

Recibo el siguiente error CORS con esto aunque estoy usando cors con express :

La respuesta a la solicitud de verificación previa no pasa la verificación de control de acceso: no tiene el estado HTTP correcto.

@4nubhav tienes que pasar una función handlePreflightRequest como esta:

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

Desde 2.0.0 , ahora puede proporcionar un objeto extraHeaders :

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

Añadido a la documentación aquí .

Uso .of("/path") en el servidor de Socket y luego lo que hago donde declaro la URL.

@4nubhav debería permitir ese encabezado con handlePreflightRequest en el lado del 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);

Actualización: en Socket.IO v3, el transportOptions ya no es necesario, simplemente puede usar:

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

Documentación para CORS:

¿Fue útil esta página
0 / 5 - 0 calificaciones

Temas relacionados

aravindsrivats picture aravindsrivats  ·  4Comentarios

BorntraegerMarc picture BorntraegerMarc  ·  4Comentarios

patrickbussmann picture patrickbussmann  ·  6Comentarios

catamphetamine picture catamphetamine  ·  3Comentarios

exilonX picture exilonX  ·  7Comentarios