New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enable psiTurk access behind firewalls and wifi routers #99

Closed
jbmartin opened this Issue May 22, 2014 · 7 comments

Comments

Projects
None yet
2 participants
@jbmartin
Copy link
Member

jbmartin commented May 22, 2014

Currently, psiTurk doesn't work behind firewalls e.g., wifi routers. A savvy user can configure port forwarding if they have physical access to the router, yet the average user lacks this ability and/or access. To get around this issue, we can use reverse tunneling to automatically punch holes in people's firewalls, similar to how Skype works. A simple way to add this functionality to psiTurk would be to setup a Ngrok server on tunnel.psiturk.org. One obstacle, however, is that Ngrok needs to run on a host with wildcard subdomain support, which is uncommon. Once we figure out the wildcard issue, psiTurk users will be able to run experiments on their home computers over any lan or wifi connection.

@jbmartin

This comment has been minimized.

Copy link
Member Author

jbmartin commented May 22, 2014

Got the self-signed ssl cert to work. All that's left is the wildcard DNS.

@gureckis

This comment has been minimized.

Copy link
Member

gureckis commented May 22, 2014

not sure the use-case but self-signed certs cause problems for some browsers. is this only for the part of getting the ssh tunnel established (in which case it's probably ok)?

@jbmartin

This comment has been minimized.

Copy link
Member Author

jbmartin commented May 22, 2014

yeah, the ssl cert is solely for the ssh tunnel (no browser).

@jbmartin

This comment has been minimized.

Copy link
Member Author

jbmartin commented May 26, 2014

psiturk/tunnel is ready to be merged into dev as soon as we get the go-ahead on *.tunnel.psiturk.org.

@jbmartin

This comment has been minimized.

Copy link
Member Author

jbmartin commented May 29, 2014

Any thoughts on the most frictionless way to reconnect to a tunnel on hit extend? It seems most natural to give users a static tunnel, but it might get confusing if they have multiple ads.

@gureckis

This comment has been minimized.

Copy link
Member

gureckis commented May 29, 2014

well, this is already sort of the case with non-tunneled servers. the ad always points to your IP address. thus, if you are running, for example, the wrong task for the ad then there's nothing you can do about it.

i guess the equivalent thing for tunnels would be to give users one or more unique tunnel DNS entries which they can connect to at will to run their studies (basically just acting as a dynamic dns type service).

it's possible a unique tunnel for each ad make sense at some level, but e.g., what is your tunnel ip before you create the ad in the first place (e.g., when debugging)? while generally not ideal, i guess i feel the simplest solution currently is to give people a tunnel DNS to use and connect to and then let them add new ones when they want? or could just be like the API keys and regenerate a new random one if for some reason you wanted to switch.

@jbmartin

This comment has been minimized.

Copy link
Member Author

jbmartin commented Jul 23, 2014

Version 2.1.0 closes this issue.

@jbmartin jbmartin closed this Jul 23, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment