5 ms·

Show HN: Tabserve.dev. HTTPS proxy using Web Workers and a Cloudflare Worker

117 points by emadda 3y ago

Tabserve gives you a https url for localhost using only the browser (tabserve.dev). Take a look: https://tabserve.dev https://tabserve.dev

sattoshi 3y ago
How does this deal with web-sockets?
- latchkey 3y ago
  Under limitations: "No WebSocket requests."
  - tuukkah 3y ago
    Under "will be fixed in future versions"
Solvency 3y ago
What sort of precautions would one need to take before just firing this up on their toy project running on localhost...
- emadda 3y ago
  The client itself is likely to be more secure than other reverse proxy CLI's as it is inside your browser sandbox. CLI's have access to all your files. You would take the same precautions as putting any other web server on the web - you might want to use a password or a hard to guess subdomain if you do not want others to access it. But I would assume you would be using test data in your dev environment. The Cloudflare WAF (Web Application Firewall) also blocks requests to your web server. I think that is just DDOS protection.
sattoshi 3y ago
Without web sockets and streaming responses, this is not very useful tbh.
- nl 3y ago
  I mean this site doesn't use websockets so perhaps your idea of not useful is somewhat limited?
- emadda 3y ago
  WebSockets will be added soon. I think streaming HTTP responses may currently work. The client forwards the response back to the original client chunk by chunk (it does not wait for the entire response). I still have more testing to do.
TechBro8615 3y ago
This is pretty awesome. I was going to ask if it is constrained by any Same Origin restrictions, but I see the note at the bottom of the page that you must "enable CORS" on the localhost server, so indeed it is constrained by such policies. Specifically, I imagine the requirement is that the server you're tunneling to respond with `Access-Control-Allow-Origin: app.tabserve.dev`. Is this correct? Or should the value be the subdomain of the cloudflare worker? In other words, which is the "origin" of the proxied requests? I assume it's `app.tabserve.dev` since the user is accessing the tunneled service through the worker subdomain which would be the value of the `Host` header.
- mattlondon 3y ago
  You can probably just use access-control-allow-origin: * to "turn off" CORS on the local server. Since you are behind the reverse proxy anyway, there is probably not much of a security implication?
  - paulgb 3y ago
    > Since you are behind the reverse proxy anyway, there is probably not much of a security implication? If you access other sites in the same browser, they'll be able to send requests to your private localhost server. I don't expect this to be a problem right now, but if it becomes a popular thing to do that might change.
    - westurner 3y ago
      With such configuration, requests to e.g. a jupyterlab/cockpit/mosh webterm on localhost - if the auth token is already stored in a cookie - thus can execute arbitrary commands as the user running an rshell on localhost.
- emadda 3y ago
  Thanks. Yes, `Access-Control-Allow-Origin: app.tabserve.dev` is correct, app.tabserve.dev is the origin where the fetch requests are made to your localhost.
neoecos 3y ago
The missing websockets support is anywhere in the roadmap?
- emadda 3y ago
  WebSockets will be added soon.
revskill 3y ago
God! No more the garbage ngrok for me.
- Bnjoroge 3y ago
  what do you hate about it? j curious
dmitri1981 3y ago
The
truemotive 3y ago
This is cool, I took a good stab at using it last night but implementing CORS in the project I wanted it for was a pain on my end. Likely my issue, they have pretty clear but unfamiliar instructions if you’re just getting into non-trivial CloudFlare management. Great concept though.
geekodour 3y ago
nice stuff, really like the ui but i am not sure if this functionally does anything different than cloudflared tunnel --url http://localhost:8080 http://localhost:8080 it's the same thing right?
- emadda 3y ago
  Thanks, yes it is the same thing. Tabserve adds a few extras: - No need to install a CLI, safer as it is in the browser sandbox. - Use the Chrome dev tools for observing requests. - Config multiple reverse proxies on different browsers remotely. - GUI. The cloudflared tunnel also supports any TCP/UDP traffic, tabserve is just for http.

117 points by emadda 3y ago

Tabserve gives you a https url for localhost using only the browser (tabserve.dev). Take a look: https://tabserve.dev https://tabserve.dev

sattoshi 3y ago

How does this deal with web-sockets?

latchkey 3y ago
Under limitations: "No WebSocket requests."
- tuukkah 3y ago
  Under "will be fixed in future versions"

Solvency 3y ago

What sort of precautions would one need to take before just firing this up on their toy project running on localhost...

emadda 3y ago
The client itself is likely to be more secure than other reverse proxy CLI's as it is inside your browser sandbox. CLI's have access to all your files. You would take the same precautions as putting any other web server on the web - you might want to use a password or a hard to guess subdomain if you do not want others to access it. But I would assume you would be using test data in your dev environment. The Cloudflare WAF (Web Application Firewall) also blocks requests to your web server. I think that is just DDOS protection.

sattoshi 3y ago

Without web sockets and streaming responses, this is not very useful tbh.

nl 3y ago
I mean this site doesn't use websockets so perhaps your idea of not useful is somewhat limited?
emadda 3y ago
WebSockets will be added soon. I think streaming HTTP responses may currently work. The client forwards the response back to the original client chunk by chunk (it does not wait for the entire response). I still have more testing to do.

TechBro8615 3y ago

This is pretty awesome. I was going to ask if it is constrained by any Same Origin restrictions, but I see the note at the bottom of the page that you must "enable CORS" on the localhost server, so indeed it is constrained by such policies. Specifically, I imagine the requirement is that the server you're tunneling to respond with `Access-Control-Allow-Origin: app.tabserve.dev`. Is this correct? Or should the value be the subdomain of the cloudflare worker? In other words, which is the "origin" of the proxied requests? I assume it's `app.tabserve.dev` since the user is accessing the tunneled service through the worker subdomain which would be the value of the `Host` header.

mattlondon 3y ago
You can probably just use access-control-allow-origin: * to "turn off" CORS on the local server. Since you are behind the reverse proxy anyway, there is probably not much of a security implication?
- paulgb 3y ago
  > Since you are behind the reverse proxy anyway, there is probably not much of a security implication? If you access other sites in the same browser, they'll be able to send requests to your private localhost server. I don't expect this to be a problem right now, but if it becomes a popular thing to do that might change.
  - westurner 3y ago
    With such configuration, requests to e.g. a jupyterlab/cockpit/mosh webterm on localhost - if the auth token is already stored in a cookie - thus can execute arbitrary commands as the user running an rshell on localhost.
emadda 3y ago
Thanks. Yes, `Access-Control-Allow-Origin: app.tabserve.dev` is correct, app.tabserve.dev is the origin where the fetch requests are made to your localhost.

neoecos 3y ago

The missing websockets support is anywhere in the roadmap?

emadda 3y ago
WebSockets will be added soon.

revskill 3y ago

God! No more the garbage ngrok for me.

Bnjoroge 3y ago
what do you hate about it? j curious

dmitri1981 3y ago

The

truemotive 3y ago

This is cool, I took a good stab at using it last night but implementing CORS in the project I wanted it for was a pain on my end. Likely my issue, they have pretty clear but unfamiliar instructions if you’re just getting into non-trivial CloudFlare management. Great concept though.

geekodour 3y ago

nice stuff, really like the ui but i am not sure if this functionally does anything different than cloudflared tunnel --url http://localhost:8080 http://localhost:8080 it's the same thing right?

emadda 3y ago
Thanks, yes it is the same thing. Tabserve adds a few extras: - No need to install a CLI, safer as it is in the browser sandbox. - Use the Chrome dev tools for observing requests. - Config multiple reverse proxies on different browsers remotely. - GUI. The cloudflared tunnel also supports any TCP/UDP traffic, tabserve is just for http.