-
Notifications
You must be signed in to change notification settings - Fork 461
misc: Don't use 0.0.0.0 as the default listen address and warn if using a loopback #2406
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
Closed
Closed
Changes from all commits
Commits
Show all changes
6 commits
Select commit
Hold shift + click to select a range
e0edda0
Revert "feat: Change default listen address to 0.0.0.0 (#2307)"
simon-lemay-unity 382bfa4
Bring back the good bits from that revert
simon-lemay-unity e1ab404
Warn if using 127.0.0.1 as the default listen address
simon-lemay-unity 1bf1e7b
Avoid the warning in many tests
simon-lemay-unity c16ba4e
Minor change to a log line
simon-lemay-unity eb41ad5
Add PR number to CHANGELOG entry
simon-lemay-unity File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we be specifically promoting use of 0.0.0.0? Seems like this message should encourage the user to think about their choice. Like "set the Server Listen Address (use 0.0.0.0 to accept all incoming connections)". I feel like the way it's worded right now has the same security concern as before because a lot of users are just going to read this and then set 0.0.0.0 while wondering why we don't just do that automatically.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree, but realistically there are only two choices here: bind to 127.0.0.1 or bind to 0.0.0.0. The key differentiator between the two being that 0.0.0.0 allows connections from remote devices. Sure, it's possible to set it to the IP address of a specific network adapter, but that's for people who know what they're doing (and they're not the audience of this warning).
The only reason to use 127.0.0.1 is security, and I'm wary of stating that in the warning because it implies that 0.0.0.0 is less secure in some way (when in fact if you want to accept remote connections you'll be opening a port to the outside anyway). To me it really boils down to whether the user needs to accept connections from remote devices or not. (The answer to that question being yes most of the time is why I originally made 0.0.0.0 the default.)
I'm open to suggestions on how to rephrase the warning, however.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suppose, but that makes me wonder if we should even have an IP entry by default or if this should be a checkbox for "Accept remote connections" and put the text box under a collapsed "advanced settings" section. Then the warning could just say "Warning: Running in local mode. Connections from remote devices will not be accepted. To change this, check 'accept remote connections' in NetworkManager settings".
If we know that most users will only be choosing between two possible values for that field, why not just make it a boolean field and hide the advanced configuration so only advanced users need to think about it at all?
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree, and in hindsight a checkbox really would have been the better option here. I'm not sure about adding this at this point, though. I'm afraid this will just add more complexity to a component (
UnityTransport) which already doesn't exactly shine by how straightforward it is to use.Adding this without breaking the API would probably require adding a custom editor component for the settings (we can't just add a separate advanced settings structure to
ConnectionDatabecauseServerListenAddressis already a member and I've seen users set it manually from code). We'll also need to add logic to harmonize the checkbox and the text field. For example, what happens if I check the box but set the bind IP to 127.0.0.1?All of that for an option which, as you astutely point out, users are just going to blindly enable and wonder why it's not the default behavior. Ultimately the IP the server binds on is a relatively minor consideration in the grand scheme of creating a multiplayer game. I think the amount of effort we put into handling it should reflect that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, a custom editor component was what I had in mind actually. No changes to the actual runtime code, just a custom editor component that fills that box with 127.0.0.1 or 0.0.0.0 as necessary based on the state of the checkbox, probably disabling the checkbox if the user's manually entered anything there.
Might be too much for a quick bugfix to go into an already-cut release branch, but since we seem to be in agreement that that'd be a better solution, maybe we could make a task for later to adjust that for 1.3.1?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, that sounds good! I think it would make a great improvement for the next release.