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.
> 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.
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.
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.
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.
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.
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.