feat(rpc): default binding to localhost vs 0.0.0.0 open to world #2955
Conversation
This file contains 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
…efault bind address refs #2824 and add some tests
… defaults as localhost for bind/listen address
ramin
requested review from
renaynay,
Wondertan,
vgonkivs,
distractedm1nd and
walldiss
as code owners
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #2955 +/- ##
==========================================
+ Coverage 50.57% 50.93% +0.36%
==========================================
Files 168 176 +8
Lines 11022 11193 +171
==========================================
+ Hits 5574 5701 +127
- Misses 4942 4988 +46
+ Partials 506 504 -2 ☔ View full report in Codecov by Sentry. |
vgonkivs
approved these changes
Dec 13, 2023
renaynay
pushed a commit
to renaynay/celestia-node
that referenced
this pull request
Jan 15, 2024
…estiaorg#2955) fixes celestiaorg#2824 which requests we bind to localhost by default (previously was world accessible) - sets defaults to bind to localhost properly (previously flags SAID the defaults were localhost but were actually 0.0.0.0) - removes an unused `DefaultConfig` defined in `api/gateway/package` - moves defaults (bind address and port) to vars so we can use them to set in flag usage messages so they don't drift out of sync with reality - adds tests for the defaults - adds test cases for flag definitions - adds test cases for flag parsing Other skips suggestion of binding vhosts, we don't do any kind of middleware checking in rpc (i believe in geth this would be a way to bind to 0.0.0.0 then limit to allowed remote IPs making requests). I'd suggest this is a more advanced configuration use case and belongs outside of the node itself to be managed by the infra operator where it'd be handled by a ingress gateway or routing rule to the machine/instance/orchestrator where the node software is running
|
I think this was actually a breaking change. If you run node in docker, you now need to add |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
fixes #2824 which requests we bind to localhost by default (previously was world accessible)
DefaultConfigdefined inapi/gateway/packageOther
skips suggestion of binding vhosts, we don't do any kind of middleware checking in rpc (i believe in geth this would be a way to bind to 0.0.0.0 then limit to allowed remote IPs making requests). I'd suggest this is a more advanced configuration use case and belongs outside of the node itself to be managed by the infra operator where it'd be handled by a ingress gateway or routing rule to the machine/instance/orchestrator where the node software is running