On 30/07/2012, at 07.15, Nathan Duran wrote: [..snip9 >> 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?
Nathan, thanks for replying. I should have been more clear here. The service is a kind of management service so the starting/stopping of the app-specific http service is actually what it is supposed to do. For other reasons the remote fork bomb is not possible in this service. What I was interested in is if Mongrel2 would support such dynamic re-configuration of proxies without needing restart or slowing other operations down (the http servers dynamically appear and disappear). >> - 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. OK, thanks for the input. I definitely will.
