On Jul 29, 2012, at 1:25 PM, Karl Krukow <[email protected]> wrote:
> - One of the operations is particularly interesting. It starts an > application-specific http server which the web service client can send http > requests to (via a "send command" operation). So the web service actually > acts as a proxy for that other special http server. Now, I was thinking that > since mongrel2 has proxy support, I would simply implement this operation by > first starting the app-specific http server and then *dynamically* changing > the mongrel2 config by adding a proxy for that server. The client would then > connect to the app-specific server via the proxy. Is that possible? Does it > sound reasonable? That does not sound very reasonable at all and may even be a recipe for remote fork bombs. Why would you even want to build something that way? > - Finally a questions about security. I see that Mongrel2 easily supports > SSL. But is there any other features that make security easier. Particularly > I'm looking to do authorization at the service level. Each of those Ruby > services need to authorize all requests that come in - whether they come from > the web service or internally. Would all http related information (e.g. Basic > Auth) be relayed from mongrel2 to the ZMQ server processes? How could a > non-mongrel zmq process connect to a service and send the same auth > information (was that question clear)? Regardless of the server in question, you're better off implementing your own auth mechanisms if you want anything to actually be secure. I've vended JSON-RPC endpoints that required embedded tickets, and I'm sure you could do something similar with OAuth headers or whatever else you wanted. There is no difference between a Mongrel ØMQ process and a non-Mongrel ØMQ process as far as ØMQ is concerned. I'd strongly recommend working through some of the example code before making any architectural decisions. They're all very short and very simple.
