linux public network IP:45456/start CROS error

[510635337]

Hello, I deployed the httptoolkit-server and httptoolkit-ui services in the main branch separately in the Linux server. I ran npm start in the httptoolkit-server directory and npm run start:web in the httptoolkit-ui directory. After the services were started successfully, I tried Use the public IP in the browser to access the UI interface. When accessing http://xxx:45456/start, a cross-domain problem is reported. Does this tool support deployment using public IP addresses? Or do I need to modify any configuration so that I can normally use the public IP to access the UI and use related functions?

[pimterry]

Hi @510635337. In general remote hosting like this isn't really supported at all, everything is currently implemented assuming the server will be run and accessed locally only (usually as an electron app).

It's quite dangerous to do this if you're not careful since the server exposes an API that is effectively unsecured arbitrary remote execution on your server. If you're currently exposing the server's ports (45456/45457) on the internet without authentication or other tight restrictions then this is a major security problem and I would recommend shutting that server down immediately (and probably re-imaging the machine entirely, in case somebody has already abused this).

It's possible to require a token for all server requests, by setting a HTK_SERVER_TOKEN env var and passing this as an authToken=... URL parameter in the UI, which would provide some authentication, but this is mostly intended as a defense-in-depth additional security mechanism, and I certainly can't guarantee it's secure against attackers on the public web.

Using a VPN to secure this, so it's not accessible publicly, is probably a reasonable approach. In terms of CORS, the issue is probably that the server doesn't trust the website URL you're using (this is configured here) - these restrictions are intended to block websites you open on your local machine from making cross-origin requests to the API listening on your localhost port (and that's in addition to the token authentication checks).

But reiterating the main point: this entire setup isn't supported, and I can't really guide you on what will work well or at all in this case. If you're planning to run the current code as-is, I would recommend only running HTTP Toolkit locally - running it remotely securely is going to require quite a few changes and some non-trivial setup work. On the other hand, if you are really interested in doing that properly, there are some long-term features planned to eventually actively support hosted/headless usage (httptoolkit/httptoolkit#288) and contributions towards actually making that work would be very welcome indeed (note that HTTP Toolkit Pro is totally free for contributors). Let me know if that sounds interesting.

[510635337]

这是来自QQ邮箱的假期自动回复邮件。   您好，我最近正在休假中，无法亲自回复您的邮件。我将在假期结束后，尽快给您回复。

[luketeam5]

This appears to be an issue on localhost as well.

[pimterry]

@luketeam5 can you share the contents of the CORS response itself? The full response might show some info.

Localhost is definitely supported in development usage, it should only fail if you're using a production server build while using the dev UI (e.g. if you try to open the UI from a dev setup whilst running the real HTTP Toolkit app).