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

Non helpful error message when started in clientonly mode #3405

Closed
tfischer4765 opened this issue Mar 27, 2024 · 7 comments
Closed

Non helpful error message when started in clientonly mode #3405

tfischer4765 opened this issue Mar 27, 2024 · 7 comments
Labels

Comments

@tfischer4765
Copy link

tfischer4765 commented Mar 27, 2024

If the client is started with the commandline node clientonly --address 127.0.0.1 --port 8080, it returns the error Usage: 'node clientonly --address 192.168.1.10 --port 8080 [--use-tls]', which is very confusing, because it is exactly what the user did just then.

This is due to the fact that in clientonly/index.js:123 function fail() is called without arguments, causing it to return exactly this default error message:

if (["localhost", "127.0.0.1", "::1", "::ffff:127.0.0.1", undefined].indexOf(config.address) === -1) { [snipsnip] } else { fail(); }

Suggestion: put an actual error message into the call to fail();

@tfischer4765
Copy link
Author

Come to think about it: Is there a logical reason to block localhost? I stumbled upon it when trying to split my PM2 config into two, so I could restart the frontend and backend individually.

@sdetweil
Copy link
Collaborator

in general there is no need to use client on the same machine

just use a browser on the docker host

@tfischer4765
Copy link
Author

But is it actually problematic? In my opinion, restrictions should not exist unless absolutely necessary. You might not see any use case right now, but somebody else might.

Look at my use case: I am running and will always run the frontend and backend on the same machine, but if I run them separately, I can change the config and restart the backend without the user even noticing the disruption, and much quicker too. There is no need to restart the frontend for a minimal config change.

My current workaround is to simply attach to the external IP of the device, but with what I currently know, I feel the restriction could be dropped completely with no ill effects whatsoever.

@sdetweil
Copy link
Collaborator

sdetweil commented Mar 27, 2024

there is no guarantee that the front end will recover when the backend is restarted.

@tfischer4765
Copy link
Author

I noticed that sometimes it will get out of sync. For my testing setup, that is no big issue. When I deploy it for real, I'll most likely go back to running it as a single task for now.

That still doesn't explain why localhost needs to be blocked in my mind, because it would be true whether you ran client and server on the same machine or on separate ones.

@sdetweil
Copy link
Collaborator

well, if you are going to run it on the same machine, then we recommend using the single instance execution

npm start
vs
npm run server
AND
npm run client

Copy link

github-actions bot commented Oct 5, 2024

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Oct 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants