Usando un zócalo Flash con Node.js

Question

He estado usando gimite/web-socket-js para implementar un WebSocket pasado simplemente Chrome y compilaciones de desarrollo de Safari. Quiero alejarme del servidor Ruby y entrar en Node.js. De repente, no funciona en nada más que en Chrome.

Sospecho que esto tiene que ver con el archivo Flash Socket Policy que debo implementar. Me gustaría implementar esto como un proceso externo de Node.js para no ensuciarme con la aplicación original. Estoy usando el node-websocket-server para implementar el protocolo WebSocket con Node.js, y de nuevo preferiría no meterme con eso tampoco.

Parecía que la cosa más simple de hacer, sería ejecutar flashsocket.js, pero en ejecución que me da el siguiente error:

sys:334 
    ctor.prototype = Object.create(superCtor.prototype, { 
          ^
TypeError: Object prototype may only be an Object or null 
    at Function.create (native) 
    at Object.inherits (sys:334:29) 
    at Object.<anonymous> (/Users/me/Projects/testing/websocket/node-websocket-server/flashsocket.js:10:16) 
    at Module._compile (node.js:472:23) 
    at Module._loadScriptSync (node.js:479:10) 
    at Module.loadSync (node.js:349:12) 
    at Object.runMain (node.js:532:24) 
    at node.js:762:10 

Aquí nos encontramos con las preciosas errores crípticos Node.js es amado por.

Mi pregunta es si existe un servidor de políticas de socket flash global independiente que pueda ejecutar Node.js u otra aplicación? Según entiendo, solo necesito que resida en el puerto 843. ¿O existe otra biblioteca WebSocket para Node.js que manejará la política de Flash como lo hace el servidor de Ruby?

Answer 1

Con un poco de ayuda de la lista de correo Node.js me ocurrió lo siguiente:

var net = require("net"), 
    domains = ["localhost:8081"]; 

net.createServer(
    function(socket) 
    { 
     socket.write("<?xml version=\"1.0\"?>\n"); 
     socket.write("<!DOCTYPE cross-domain-policy SYSTEM \"http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd\">\n"); 
     socket.write("<cross-domain-policy>\n"); 

     domains.forEach(
      function(domain) 
      { 
       var parts = domain.split(':'); 
       socket.write("<allow-access-from domain=\""+parts[0]+"\"to-ports=\""+(parts[1]||'80')+"\"/>\n"); 
      } 
     ); 

     socket.write("</cross-domain-policy>\n"); 
     socket.end(); 
    } 
).listen(843); 

También escribí un (breve) tutorial para WebSockets applications using Flash Sockets.

Answer 2

Es mejor anular los oyentes de Stream (oyentes de socket). de lo contrario su servidor estrellarse cuando se tiene algún error como:

ECONNRESET, Connection reset by peer

Ejemplo de aplicación para evitarlo:

socket.setEncoding("utf8"); 
socket.addListener("end", function() {socket.end();}); 
socket.addListener("error", function (exception) {socket.end();}); 
socket.addListener("timeout", function() {socket.end();}); 
socket.addListener("close", function (had_error) {socket.end();}); 

Ver documentación en: http://nodejs.org/api.html (en "net.Stream")

Answer 3

Las solicitudes de políticas de Flash también se pueden responder en línea en el mismo puerto que el servicio WebSockets que está brindando. Consulte this change en el módulo Socket.IO node.js. Agrega una conexión para escuchar al servidor que responde a las solicitudes del servidor de políticas en el mismo puerto. De esta forma, no tiene que ejecutar algo en el puerto 843 (que generalmente requiere privilegios de administrador).

Alternativamente, también puede ejecutar una directiva de servidor petición muy sencilla (2 líneas) utilizando socat (suponiendo que usted está en un sistema * nix): http://github.com/kanaka/noVNC/blob/master/docs/flash_policy.txt

actualización (respuesta a @ Josh K):

Es un malentendido común que el puerto 843 es la ubicación principal para las solicitudes de políticas flash y que las solicitudes del mismo puerto son un retroceso y que son más lentas debido al tiempo de espera. Esto probablemente se basa en el comúnmente citado http://www.lightsphere.com/dev/articles/flash_socket_policy.html y también porque la documentación de Adobe es difícil de rastrear (y leer). Aquí está la documentación de Adobe sobre su política de seguridad: http://www.adobe.com/devnet/flashplayer/articles/fplayer9_security.html

En realidad, el puerto 843 sirve un propósito diferente de la misma respuesta de puerto.El puerto 843 es para la meta-política (sitio-política). Tiene prioridad sobre las políticas del mismo puerto. El administrador puede usarlo para definir políticas flash para todo el sistema y puede usarlo para denegar a los usuarios no privilegiados la autorización de conexiones de socket flash entrantes. Esta es la razón por la que está en el puerto 843 (que se encuentra en el rango privilegiado) para que solo el administrador del sistema pueda iniciar el servicio en ese puerto.

El tiempo de espera de 3 segundos solo se aplica en el caso en que las conexiones al puerto 843 se eliminan silenciosamente. No se aplica al caso donde hay algún otro servicio ejecutándose en el puerto 843 o la conexión es rechazada (es decir, reinicio de TCP). Uso same-port todo el tiempo y no hay un retraso perceptible con solo ejecutar un mismo servidor de políticas portuarias.

Con un servidor WebSocket, una ventaja adicional de la respuesta de política del mismo puerto es que puede coordinar más fácilmente la configuración de la política de origen entre la política de flash y el protocolo de enlace WebSockets.