[tor-talk] Testing flashproxy

[David Fifield]

On Sun, Jan 13, 2013 at 07:53:12PM +0100, Andreas Krey wrote:
> > Maybe you could run flashproxy.js with the Rhino JavaScript interpreter
> > (we already use Rhino for some of our tests). You would need to make
> > some changes to flashproxy.js to remvoe some of the browser assumptions.
> 
> After arma's bug comment I turned down the python road (instead of
> rhino/nodejs), and wonder what would be a good setup for testing. I'd
> obviously need a dummy facilitator, and two web socket server that try
> to communicate over that. Is there something readily available?

You should start without a facilitator. Just make your standalone
program take a client and relay address on the command line. The client
can be 127.0.0.1 (you run flashproxy-client locally) and the relay can
be tor1.bamsoftware.com:9901. flashproxy.js can also be run in this way,
bypassing the facilitator:
http://crypto.stanford.edu/flashproxy/flashproxy.js?debug&client=127.0.0.1:9000&relay=173.255.221.44:9901

The websocket server transport plugin is in a branch of the flashproxy
source code. It's not hard to install if you have the golang tools
already.
https://gitweb.torproject.org/user/dcf/flashproxy.git/tree/transport:/websocket-transport

We previously used a third-party WebSocket transport called websockify.
https://github.com/kanaka/websockify

When you want to run with your own facilitator, documentation for doing
it is here. You can omit most of the instructions; basically you just
need to run an Apache CGI and another process locally. You won't be able
to use the Gmail-based rendezvous because that requires secret keys, but
you can use the trivial HTTP-based rendezvous for testing.
https://gitweb.torproject.org/flashproxy.git/blob/HEAD:/doc/facilitator-howto.txt

> Btw, in the onreadystatechange handling the .js code seems to drop
> the ball, that is, forget to set the timer when the xhr status
> isn't 200 - thus no longer polling the facilitator.

This is intentional. If there's any error the proxy disables itself. We
err towards the side of a proxy going silent rather than going haywire.

David