Skip to content
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
Closed

Enable psiTurk access behind firewalls and wifi routers #99

jbmartin opened this issue May 22, 2014 · 7 comments

Comments

@jbmartin
Copy link
Member

@jbmartin 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
Copy link
Member Author

@jbmartin jbmartin commented May 22, 2014

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

@gureckis
Copy link
Member

@gureckis 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
Copy link
Member Author

@jbmartin jbmartin commented May 22, 2014

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

@jbmartin
Copy link
Member Author

@jbmartin 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
Copy link
Member Author

@jbmartin 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
Copy link
Member

@gureckis 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
Copy link
Member Author

@jbmartin 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
Labels
None yet
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants