You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
Right now if I call Servers.startOnPort(...) there's only one argument, for the port and the host defaults to the loopback interface which makes the whole thing useless if you need to bind to 0.0.0.0 or any other network interface.
Describe the solution you'd like
Add an optional host argument that defaults to loopback for both security and backwards compatibility reasons.
Describe alternatives you've considered
Considered not having the host arg as optional but decided against it since we have a default value for it that can be considered both secure and backwards compatible (a rare, but most welcome sight in software engineering)
Additional context
This came up as part of the ongoing work to containerize the project, more specifically the supply chain app example (the containerization of which is mostly equivalent to having containerized the entire project anyway since it uses most of the existing packages of Cactus - aka it's a top level package).
Extends the existing functionality of the utility method so that it can
accept a 'host' parameter where callers can
specify if they want to bind to the wildcard
network interface of `0.0.0.0` for example.
The default option of the host argument is
localhost so that we are *secure by default*
even if this method is only used for testing
code, it cannot hurt to be on the safe side.
Fixeshyperledger#527
Signed-off-by: Peter Somogyvari <peter.somogyvari@accenture.com>
Extends the existing functionality of the utility method so that it can
accept a 'host' parameter where callers can
specify if they want to bind to the wildcard
network interface of `0.0.0.0` for example.
The default option of the host argument is
localhost so that we are *secure by default*
even if this method is only used for testing
code, it cannot hurt to be on the safe side.
Fixes#527
Signed-off-by: Peter Somogyvari <peter.somogyvari@accenture.com>
(cherry picked from commit ddbad37)
Extends the existing functionality of the utility method so that it can
accept a 'host' parameter where callers can
specify if they want to bind to the wildcard
network interface of `0.0.0.0` for example.
The default option of the host argument is
localhost so that we are *secure by default*
even if this method is only used for testing
code, it cannot hurt to be on the safe side.
Fixes#527
Signed-off-by: Peter Somogyvari <peter.somogyvari@accenture.com>
jordigiam
pushed a commit
to kikoncuo/cactus
that referenced
this issue
Feb 11, 2021
Extends the existing functionality of the utility method so that it can
accept a 'host' parameter where callers can
specify if they want to bind to the wildcard
network interface of `0.0.0.0` for example.
The default option of the host argument is
localhost so that we are *secure by default*
even if this method is only used for testing
code, it cannot hurt to be on the safe side.
Fixeshyperledger#527
Signed-off-by: Peter Somogyvari <peter.somogyvari@accenture.com>
Is your feature request related to a problem? Please describe.
Right now if I call
Servers.startOnPort(...)
there's only one argument, for the port and the host defaults to the loopback interface which makes the whole thing useless if you need to bind to0.0.0.0
or any other network interface.Describe the solution you'd like
Add an optional
host
argument that defaults to loopback for both security and backwards compatibility reasons.Describe alternatives you've considered
Considered not having the host arg as optional but decided against it since we have a default value for it that can be considered both secure and backwards compatible (a rare, but most welcome sight in software engineering)
Additional context
This came up as part of the ongoing work to containerize the project, more specifically the supply chain app example (the containerization of which is mostly equivalent to having containerized the entire project anyway since it uses most of the existing packages of Cactus - aka it's a top level package).
cc: @takeutak @sfuji822 @hartm @jonathan-m-hamilton @AzaharaC @jagpreetsinghsasan @jordigiam @kikoncuo
The text was updated successfully, but these errors were encountered: