[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-talk] Testing flashproxy
On Sun, Jan 13, 2013 at 07:53:12PM +0100, Andreas Krey wrote:
> > (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:
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
We previously used a third-party WebSocket transport called 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.
> 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.
tor-talk mailing list