Public server mode

[digital-dreamer]

I whitelisted just the calls needed by UI in public server mode. I am really new to this project, so it would be great if someone could check the security of running this open on the web.

[miguelfreitas]

listwalletusers... true?

i'm inclined to accept it, but probably simply exposing twisterd to the world is not the best solution. i think maybe doing a node.js server in front of twisterd would be more secure and also allow for easy caching of requests, in order to lower the twister network traffic (also prevent this node to be blocked if generating too much dht requests)

[digital-dreamer]

Listwalletusers is not forbidden, but returns just an empty array - you can see it in the change in src/rpcwallet.cpp, I chose this only to preserve compatibility with user initialization in the UI, but we could also rewrite it there and make listwalletusers return an error in public mode, I think both should be equally secure.

We could make a special front end in node.js, but I was thinking of a simpler way - run it on a webserver like nginx via CGI gateway. That way we can get SSL and caching and all that stuff without a need to write a separate front end. This is the way Mediagoblin does it. Do you think it could work with Twister?

[miguelfreitas]

ah, ok about listwalletusers. merging.

[miguelfreitas]

btw, while secure, some of these calls might cause significant load on your system so a denial of service is possible... the node.js proxy could also be used to limit the number of requests/second.

[digital-dreamer]

Yes, that will protect the system, but it will lock out legitimate requests too. Something like a QoS would be even better - for example, it could allow only certain amount (rate) of requests per client IP, and start discarding those coming from the same source after some upper limit is reached. This is a common problem, so I think someone probably implemented a solution we can use. I will look for existing open source QoS libraries, and see what the options for preventing such DoS are.

[miguelfreitas]

@digital-dreamer imho, network QoS is not what you want. This will limit the traffic, regardless of what it is. What you want is a application level filter or proxy, which can apply not only per-client limits but also on a command basis. With a RPC proxy you may set a specific limits on some costly commands only (like commands/second/client).

[iShift]

And what argument for public server?

UPD, founded -public_server_mode=1

[digital-dreamer]

miguelfreitas -> OK, so an RPC proxy is the way to go.

iShift -> yes, correct. The argument doesn't do anything interesting alone, all the changes happen in the front end (pull miguelfreitas/twister-html#135) .