4 ms·
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 "ena
by 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 agoYou 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 agoWith 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 agoThanks. 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.