Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

linux public network IP:45456/start CROS error #110

Open
510635337 opened this issue Apr 2, 2024 · 2 comments
Open

linux public network IP:45456/start CROS error #110

510635337 opened this issue Apr 2, 2024 · 2 comments

Comments

@510635337
Copy link

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?
image

image

@pimterry
Copy link
Member

pimterry commented Apr 2, 2024

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
Copy link
Author

510635337 commented Apr 2, 2024 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants