3 ms·

Websockets zeromq proxying

24 points by hogu 15y ago

a-priori 15y ago
Interesting idea, but a huge security nightmare. Essentially you're opening the door for anyone to send and receive arbitrary ZeroMQ messages to any address via your server, bypassing any outward-facing firewall that might be in place. One way to make this a bit less of a nightmare is to give the addresses via a server name, and have the proxy map that to an address. That way, the Javascript code can only access specific services known by the proxy.
- hogu 15y ago
  yes, agreed, I provide 2 functions, one which you override to determine whether a given websocket can connect, and one where you determine whether a given fake zmq socket can connect. you should definitely override both and set them to something sane a list of allowed connection sockets, etc... I might end up making a list of allowed sockets required in the future, or go with your approach of requiring some mapping of strings -> sockets, so chatservice -> tcp://127.0.0.1:9001 for example and then teh client must reference chatservice, rather than tcp://127.0.0.1:9001
jrussbowman 15y ago
Interesting idea. Are you planning on opening up other zeromq protocols like pub/sub? The web server could validate the subscription before establishing the connection. That would be a little easier for setting up control over who has access to what resources. I suppose you could do this with REQ/REP but PUB/SUB would simplify the server side implementation. For my current project I'm using PUSH/PULL with filtering at the server because it was fewer connections to deal with between the web server and zeromq router. PUB/SUB directly between the router and end user client could potentially cut down on bandwidth for a large implementation.
- hogu 15y ago
  I have already opened up SUB sockets, so that on the JS side can connect as a SUB socket to a PUB - do you mean allowing the JS side to connect as a PUB? In its current state, people who connect as a SUB socket have the option of passing in a msgfilter in their authentication data, the rationale being that you might only want to authenticate certain users to listen to certain types of messages.
- hogu 15y ago
  I also wanted to mention, that on the REQ REP side, in the bridge I actually implement the REQ as an XREQ socket, that way I only need one XREQ socket for all js side REQ sockets. I simply tag the message with the identity of the js REQ socket. I had thought it would be nice originally to create a one to one mapping between javscript side REQ sockets and server side REQ sockets, however creating one zmq socket per js client may present scaling problems, running out of file descriptors, etc..
Loic 15y ago
If you really want to easily bridge websocket in the front-end with a backend using ZeroMQ, please take a look at Mongrel2. You get that plus a wonderful webserver. Mongrel2: http://www.mongrel2.org http://www.mongrel2.org
- ominous_prime 15y ago
  Mongrel2 has some great ideas behind it, but it just doesn't seem to be able to generate any momentum in uptake or community "buzz". I think it may be solving problems which just aren't big enough for most people to warrant the switch in their technology stack. HTTP proxying and text config files work "good enough". Maybe everyone else is like me, and waiting for feedback from some big deployments in order to see how it all works in practice.
  - mvzink 15y ago
    Ironically, your comment just inspired me to try out Mongrel2. Even during its initial buzz, I never looked into Mongrel2 at all because I simply had no need for a new web server. Well, after finally looking at it... it looks fricking sweet and I can't wait to play around with it.
  - batista 15y ago
    Actually, it solves quite big problems, people are using Node, Tornado etc for nowadays, and it also uses them in a uniform way with more traditional problems, and with far more flexibility and agnosticity (language, network, etc). The problem is it doesn't have enough "marketing" behind it, for many reasons: it's not dead easy to setup yet, it doesn't use a language du jour like Javascript, it's not related to Rails...

24 points by hogu 15y ago

Interesting idea, but a huge security nightmare. Essentially you're opening the door for anyone to send and receive arbitrary ZeroMQ messages to any address via your server, bypassing any outward-facing firewall that might be in place. One way to make this a bit less of a nightmare is to give the addresses via a server name, and have the proxy map that to an address. That way, the Javascript code can only access specific services known by the proxy.

hogu 15y ago
yes, agreed, I provide 2 functions, one which you override to determine whether a given websocket can connect, and one where you determine whether a given fake zmq socket can connect. you should definitely override both and set them to something sane a list of allowed connection sockets, etc... I might end up making a list of allowed sockets required in the future, or go with your approach of requiring some mapping of strings -> sockets, so chatservice -> tcp://127.0.0.1:9001 for example and then teh client must reference chatservice, rather than tcp://127.0.0.1:9001

jrussbowman 15y ago

Interesting idea. Are you planning on opening up other zeromq protocols like pub/sub? The web server could validate the subscription before establishing the connection. That would be a little easier for setting up control over who has access to what resources. I suppose you could do this with REQ/REP but PUB/SUB would simplify the server side implementation. For my current project I'm using PUSH/PULL with filtering at the server because it was fewer connections to deal with between the web server and zeromq router. PUB/SUB directly between the router and end user client could potentially cut down on bandwidth for a large implementation.

hogu 15y ago
I have already opened up SUB sockets, so that on the JS side can connect as a SUB socket to a PUB - do you mean allowing the JS side to connect as a PUB? In its current state, people who connect as a SUB socket have the option of passing in a msgfilter in their authentication data, the rationale being that you might only want to authenticate certain users to listen to certain types of messages.
hogu 15y ago
I also wanted to mention, that on the REQ REP side, in the bridge I actually implement the REQ as an XREQ socket, that way I only need one XREQ socket for all js side REQ sockets. I simply tag the message with the identity of the js REQ socket. I had thought it would be nice originally to create a one to one mapping between javscript side REQ sockets and server side REQ sockets, however creating one zmq socket per js client may present scaling problems, running out of file descriptors, etc..

Loic 15y ago

If you really want to easily bridge websocket in the front-end with a backend using ZeroMQ, please take a look at Mongrel2. You get that plus a wonderful webserver. Mongrel2: http://www.mongrel2.org http://www.mongrel2.org

ominous_prime 15y ago
Mongrel2 has some great ideas behind it, but it just doesn't seem to be able to generate any momentum in uptake or community "buzz". I think it may be solving problems which just aren't big enough for most people to warrant the switch in their technology stack. HTTP proxying and text config files work "good enough". Maybe everyone else is like me, and waiting for feedback from some big deployments in order to see how it all works in practice.
- mvzink 15y ago
  Ironically, your comment just inspired me to try out Mongrel2. Even during its initial buzz, I never looked into Mongrel2 at all because I simply had no need for a new web server. Well, after finally looking at it... it looks fricking sweet and I can't wait to play around with it.
- batista 15y ago
  Actually, it solves quite big problems, people are using Node, Tornado etc for nowadays, and it also uses them in a uniform way with more traditional problems, and with far more flexibility and agnosticity (language, network, etc). The problem is it doesn't have enough "marketing" behind it, for many reasons: it's not dead easy to setup yet, it doesn't use a language du jour like Javascript, it's not related to Rails...