I want to clarify why this project exists (as many seem to point out that other projects or methods exist for doing this).
TL;DR; If you think of localtunnel as just a shitty ngrok (or name your project here), you are missing the point and probably don't have the same use cases I do.
1. It was made overnight at some hackathon because I was not satisfied with the other tunneling options I found. They required either an account or some stupid ssh setup. I got to thinking of ways to create a tunnel that simply had an CLI tool and instantly get a tunnel no setup. It worked, I kept it.
2. It is written as a library first, CLI tool second. This means it can be used to create tunnels in a test suite if you want to use services like saucelabs to run browser tests (see https://github.com/defunctzombie/zuul). This is leveraged by projects like socket.io and engine.io (among others). This is perhaps the main reason I keep it around despite there being alternative CLI tools.
3. Both the client and server code are availably and easy to install and use. Companies do this when they want to run their own tunnels for privacy (or whatever their reasons... I don't care).
4. Yes, I know the name is identical to the old ruby?python? one. Whatever. That one seems defunct now anyway.
ngrok doesn't have a programmatic API, but I'd love to add one soon. I've built out a library for this in https://github.com/inconshreveable/go-tunnel that will be the foundation for ngrok's next version providing a library in addition to the CLI tool.
Unfortunately, one of Go's weaknesses is that it doesn't embed into other languages like C, so I'd need a ground-up rewrite (in C, probably) with bindings to other languages.
If ngrok the command-line tool had a well defined programmatic interface (like RESTful JSON) would that useful, or is the burden of a separate binary/process to manage still too painful?
I've never heard of ngrok, but the instantly obvious use-case is to allow testing of webhooks to my local machine. In the past we've done this by booting a temporary server on AWS and remote forwarding to our local machines, which is quite a bit more complicated. I already work on a node stack, so the npm install is wonderful. I expect I'll get a lot of use out of this. Thanks!
I'm confused, there is an existing project called localtunnel that does exactly the same thing and dominates search results for "localtunnel". At the very least, pick a different name.
This seems like a bad idea. localtunnel.me is redirecting non-tunnel'd subdomains to its main page, while inactive tunnel'd subdomains return "localtunnel error: no active client for 'adbc'". So, with a little poking, you find that tunnel'd subdomains seem to be [a-z0-9]{4}.localtunnel.me ... which isn't too terribly large of a search space to crawl. If it gets popular, it should be easy to find works-in-progress that might give up access to the user's computer, or keys to prod, or any of the other stuff that people are a little sloppy about on their work machines.
edit: I was wrong, I should've been a little more thorough. Looks like it's [a-z0-9]{4,10}.localtunnel.me, which is significantly larger.
Also: Vagrant has added a "vagrant share" command that publishes access to your vagrant box, which should be safer than publishing access to your full machine.
Personally I would rather just use "ssh -R", the built in remote port forwarding. You either need to flip a setting on the server to allow listening on an interface besides localhost, or configure Nginx/etc as a reverse proxy.
That's what I've used in the past, but its more complicated to set up ("You either need to flip a setting on the server to allow listening on an interface besides localhost, or configure Nginx/etc as a reverse proxy." is not trivial for most). It also requires a server with a static IP to ssh to.
This seems like a bad idea or to phrase it correctly: use it wisely.
Because, you will use this service for the development to give someone outside access to something. If you then close the tunnel, the service will forward any request to its own server either to the main pager or to an error page. That means, all data given with a request, either via GET or via POST, will be given to that service. That could include sensitive data. That means, this kind of service is security risk.
There's also http://httpi.pe/ - pretty similar both in concept and in implementation. The major difference would be an 'inspection' view allowing users to view the traffic going through the tunnel.
Or at least get to reuse an URL after reboot/dc/something, since this is links you would send to your client/boss, having to email them new ones is a hassle.
shtylman|12 years ago
I want to clarify why this project exists (as many seem to point out that other projects or methods exist for doing this).
TL;DR; If you think of localtunnel as just a shitty ngrok (or name your project here), you are missing the point and probably don't have the same use cases I do.
1. It was made overnight at some hackathon because I was not satisfied with the other tunneling options I found. They required either an account or some stupid ssh setup. I got to thinking of ways to create a tunnel that simply had an CLI tool and instantly get a tunnel no setup. It worked, I kept it.
2. It is written as a library first, CLI tool second. This means it can be used to create tunnels in a test suite if you want to use services like saucelabs to run browser tests (see https://github.com/defunctzombie/zuul). This is leveraged by projects like socket.io and engine.io (among others). This is perhaps the main reason I keep it around despite there being alternative CLI tools.
3. Both the client and server code are availably and easy to install and use. Companies do this when they want to run their own tunnels for privacy (or whatever their reasons... I don't care).
4. Yes, I know the name is identical to the old ruby?python? one. Whatever. That one seems defunct now anyway.
inconshreveable|12 years ago
ngrok doesn't have a programmatic API, but I'd love to add one soon. I've built out a library for this in https://github.com/inconshreveable/go-tunnel that will be the foundation for ngrok's next version providing a library in addition to the CLI tool.
Unfortunately, one of Go's weaknesses is that it doesn't embed into other languages like C, so I'd need a ground-up rewrite (in C, probably) with bindings to other languages.
If ngrok the command-line tool had a well defined programmatic interface (like RESTful JSON) would that useful, or is the burden of a separate binary/process to manage still too painful?
thedufer|12 years ago
kevinburke|12 years ago
http://progrium.com/localtunnel/
pennig|12 years ago
bosky101|12 years ago
unknown|12 years ago
[deleted]
julianwachholz|12 years ago
As a bonus, you also get:
- Custom (sub) domains
- TLS tunnels if you want, not mandatory
- Other protocols than just HTTP/S
nXqd|12 years ago
_cbb1|12 years ago
thaumaturgy|12 years ago
edit: I was wrong, I should've been a little more thorough. Looks like it's [a-z0-9]{4,10}.localtunnel.me, which is significantly larger.
JamyDev|12 years ago
WARNING: server returned more data than it should - server is vulnerable! (Heartbleed)
vayarajesh|12 years ago
jancborchardt|12 years ago
yownie|12 years ago
rabino|12 years ago
http://docs.vagrantup.com/v2/share/
tedchs|12 years ago
For example:
ssh -f -N -q -R 2222:localhost:22 my_name@remote.example.com
Decent writeup here:
http://www.noah.org/wiki/SSH_tunnel
thedufer|12 years ago
j0k3r|12 years ago
Or the Go version: https://github.com/inconshreveable/ngrok
jzwinck|12 years ago
nathancahill|12 years ago
PinguTS|12 years ago
Because, you will use this service for the development to give someone outside access to something. If you then close the tunnel, the service will forward any request to its own server either to the main pager or to an error page. That means, all data given with a request, either via GET or via POST, will be given to that service. That could include sensitive data. That means, this kind of service is security risk.
superuser2|12 years ago
cardamomo|12 years ago
I'm sure I'm missing some obvious disadvantage…
IceDane|12 years ago
eranrund|12 years ago
(Shameless plug - I'm the author of httpipe)
veesahni|12 years ago
jbrooksuk|12 years ago
unknown|12 years ago
[deleted]
unknown|12 years ago
[deleted]
chintan39|12 years ago
maaaats|12 years ago
shtylman|12 years ago
vayarajesh|12 years ago
asaddhamani|12 years ago