Validate grpc port info in GRPCServer ctor #4560
Conversation
…ormation in ServerHandler. Pass the responsibility of grpc port information validation to GRPCServer constructor. Both GRPCServer and ServerHandler are created during the construction of Application instance.
|
|
||
| // grpc ports are parsed by GRPCServer class. Do not validate | ||
| // grpc port information in this file. | ||
| if (name == "port_grpc") |
There was a problem hiding this comment.
"port_grpc" should probably be defined as a constant somewhere
|
I agree that "port_grpc" should be defined as a constant, but it has been
used as a string all throughout the codebase.
If I were to define it as a constant, which file is appropriate ? Such a
file could accommodate many such constants pertaining to the config file.
Regards,
Keshava
…On Tue, Jun 6, 2023 at 7:22 PM CJ Cobb ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In src/ripple/rpc/impl/ServerHandlerImp.cpp
<https://urldefense.com/v3/__https://github.com/XRPLF/rippled/pull/4560*discussion_r1220719966__;Iw!!PZTMFYE!5tLyeqykJ7J9Kxm5vohhqQ96cYrzVUPClsqKwGJRM_5zXMhQR8VKNJBn7PLEPOc0Nxr8qhrf0ZZmqszmtoJek20ITQ$>
:
> @@ -1148,6 +1148,12 @@ parse_Ports(Config const& config, std::ostream& log)
log << "Missing section: [" << name << "]";
Throw<std::exception>();
}
+
+ // grpc ports are parsed by GRPCServer class. Do not validate
+ // grpc port information in this file.
+ if (name == "port_grpc")
port_grpc should probably be defined as a constant somewhere
—
Reply to this email directly, view it on GitHub
<https://urldefense.com/v3/__https://github.com/XRPLF/rippled/pull/4560*pullrequestreview-1466475562__;Iw!!PZTMFYE!5tLyeqykJ7J9Kxm5vohhqQ96cYrzVUPClsqKwGJRM_5zXMhQR8VKNJBn7PLEPOc0Nxr8qhrf0ZZmqszmtoJxrrS0sQ$>,
or unsubscribe
<https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/AFB4TNP2AO54J5MLF2NBYGTXJ7QWNANCNFSM6AAAAAAY5DKYNA__;!!PZTMFYE!5tLyeqykJ7J9Kxm5vohhqQ96cYrzVUPClsqKwGJRM_5zXMhQR8VKNJBn7PLEPOc0Nxr8qhrf0ZZmqszmtoI2dUsetw$>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
At the moment that file is probably src/ripple/core/ConfigSections.h. There are a bunch of macros starting with |
|
Okay, thanks for the help @scott Schurr ***@***.***> !
Several subsections of the [server] section in the configuration file like
"port_peer", "port_ws" are being used as strings inside the codebase. I
think we should refactor such occurrences as global constants in this file.
Regards,
Keshava
…On Wed, Jun 7, 2023 at 12:11 PM Scott Schurr ***@***.***> wrote:
If I were to define it as a constant, which file is appropriate?
At the moment that file is probably src/ripple/core/ConfigSections.h.
There are a bunch of macros starting with SECTION_ in that file to give
names for config sections.
—
Reply to this email directly, view it on GitHub
<https://urldefense.com/v3/__https://github.com/XRPLF/rippled/pull/4560*issuecomment-1581368119__;Iw!!PZTMFYE!6gByJrzaDBvW6kfjbH6T3pdgBC7foricbqOIFFBUXfhNuAnO7drbjetu2LGkmDya1X34hbsl94GSHn-YF7-DsDq7dg$>,
or unsubscribe
<https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/AFB4TNPRPJVAIUWBBQWHF6DXKDG6BANCNFSM6AAAAAAY5DKYNA__;!!PZTMFYE!6gByJrzaDBvW6kfjbH6T3pdgBC7foricbqOIFFBUXfhNuAnO7drbjetu2LGkmDya1X34hbsl94GSHn-YF79E8J_FRA$>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
"port_peer" and "port_ws" are only found in test code and the example config file. That's because the sections listed under |
|
@ximinez Okay, thanks. I didn't realise that. Do you have any suggestions
for the appropriate file to keep these constants? I thought `test/jtx.h` or
`test/jtx/Env.h` might be appropriate since they include many useful
functions.
@cjcobb
I've made the suggested changes to "port_grpc" constant. Do I still need to
change "port_grpc" to "grpc" in the documentation?
Regards,
Keshava
…On Thu, Jun 8, 2023 at 3:30 PM Ed Hennis ***@***.***> wrote:
Okay, thanks for the help @scott
<https://urldefense.com/v3/__https://github.com/scott__;!!PZTMFYE!8TnzHmVw_70ckZ-YQNWoJnxOEC2uSfTSLxTc_34xRTb8NQNvbYjBxuMc9N5x7SkLNrze4-jJJzu12B8qVdob45QakA$>
Schurr *@*.***> ! Several subsections of the [server] section in the
configuration file like "port_peer", "port_ws" are being used as strings
inside the codebase. I think we should refactor such occurrences as global
constants in this file. Regards, Keshava
"port_peer" and "port_ws" are only found in test code and the example
config file. That's because the sections listed under [server] can
actually be named anything that isn't already reserved. "port_peer" and
"port_ws" are only examples / suggestions. I don't think that necessitates
global constants, though maybe constants under test would be valuable.
—
Reply to this email directly, view it on GitHub
<https://urldefense.com/v3/__https://github.com/XRPLF/rippled/pull/4560*issuecomment-1583480592__;Iw!!PZTMFYE!8TnzHmVw_70ckZ-YQNWoJnxOEC2uSfTSLxTc_34xRTb8NQNvbYjBxuMc9N5x7SkLNrze4-jJJzu12B8qVdpfntZUag$>,
or unsubscribe
<https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/AFB4TNMLIZVZ2TZXXPL75QTXKJHAXANCNFSM6AAAAAAY5DKYNA__;!!PZTMFYE!8TnzHmVw_70ckZ-YQNWoJnxOEC2uSfTSLxTc_34xRTb8NQNvbYjBxuMc9N5x7SkLNrze4-jJJzu12B8qVdoXct0MWQ$>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
I'd suggest
Since you're not changing the name in the code, my vote is to not change the name in the documentation. |
|
Okay.
Regards,
Keshava
…On Fri, Jun 9, 2023 at 9:52 AM Ed Hennis ***@***.***> wrote:
Okay, thanks. I didn't realise that. Do you have any suggestions for the
appropriate file to keep these constants? I thought test/jtx.h or
test/jtx/Env.h might be appropriate since they include many useful
functions.
I'd suggest test/jtx/envconfig.h, since the "canonical" usage is in
envconfig.cpp, and it's included in a bunch of places.
I've made the suggested changes to "port_grpc" constant. Do I still need
to change "port_grpc" to "grpc" in the documentation?
Since you're not changing the name in the code, my vote is to not change
the name in the documentation.
—
Reply to this email directly, view it on GitHub
<https://urldefense.com/v3/__https://github.com/XRPLF/rippled/pull/4560*issuecomment-1584882498__;Iw!!PZTMFYE!_Y0S1c7mbI5ilaBNOvf5pBvHT8igCgrqUzNAz5MJYe1yzc_phR3nX7EYOXqmkhbfvYrlmJUXFGw7fhRCHSV5IcHPpA$>,
or unsubscribe
<https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/AFB4TNPJ6AZSC4Q2CV5BJLDXKNIDXANCNFSM6AAAAAAY5DKYNA__;!!PZTMFYE!_Y0S1c7mbI5ilaBNOvf5pBvHT8igCgrqUzNAz5MJYe1yzc_phR3nX7EYOXqmkhbfvYrlmJUXFGw7fhRCHSW0Tbc7JQ$>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
|
Ok, I've made the suggested changes. Let me know if this is okay. |
|
This change prevents rippled from stopping with But it doesn't log anything like the others do: so I can't really tell if its enabled or not when the |
src/ripple/app/main/GRPCServer.cpp
Outdated
| @@ -427,9 +428,9 @@ GRPCServerImpl::GRPCServerImpl(Application& app) | |||
| : app_(app), journal_(app_.journal("gRPC Server")) | |||
| { | |||
| // if present, get endpoint from config | |||
| if (app_.config().exists("port_grpc")) | |||
| if (app_.config().exists(PORT_GRPC)) | |||
There was a problem hiding this comment.
@legleux Apologies for the late reply.
I can include an else section and I can log the details at this juncture. Would that help in addressing your previous concern?
There was a problem hiding this comment.
I guess it really depends if this section behaves the same as the other ones.
I don't remember now how I came across my previous concern but it was not a very important one.
|
@legleux - will you be able to have a look at this? See ckeshava's reply above. |
|
I applied the patch file generated by github actions, but it doesn't modify any files :/ |
Do you have anything set up to run |
|
thanks Ed, I might have added a pre-commit hook a few months ago. |
ckeshava
changed the title
|
@intelliot This PR is ready for merging into develop. The first few commits haven't been signed because I was not aware of the procedure for signing them. Can I rebase/squash all the commits into one single signed commit with an appropriate commit message? |
Yes. |
(File was already removed from the source)
Add new transaction submission API field, "sync", which determines behavior of the server while submitting transactions: 1) sync (default): Process transactions in a batch immediately, and return only once the transaction has been processed. 2) async: Put transaction into the batch for the next processing interval and return immediately. 3) wait: Put transaction into the batch for the next processing interval and return only after it is processed.
* Verify accepted ledger becomes validated, and retry with a new consensus transaction set if not. * Always store proposals. * Track proposals by ledger sequence. This helps slow peers catch up with the rest of the network. * Acquire transaction sets for proposals with future ledger sequences. This also helps slow peers catch up. * Optimize timer delay for establish phase to wait based on how long validators have been sending proposals. This also helps slow peers to catch up. * Fix impasse achieving close time consensus. * Don't wait between open and establish phases.
…LF#4620) For the `account_tx` and `noripple_check` methods, perform input validation for optional parameters such as "binary", "forward", "strict", "transactions". Previously, when these parameters had invalid values (e.g. not a bool), no error would be returned. Now, it returns an `invalidParams` error. * This updates the behavior to match Clio (https://github.com/XRPLF/clio). * Since this is potentially a breaking change, it only applies to requests specifying api_version: 2. * Fix XRPLF#4543.
A bridge connects two blockchains: a locking chain and an issuing chain (also called a mainchain and a sidechain). Both are independent ledgers, with their own validators and potentially their own custom transactions. Importantly, there is a way to move assets from the locking chain to the issuing chain and a way to return those assets from the issuing chain back to the locking chain: the bridge. This key operation is called a cross-chain transfer. A cross-chain transfer is not a single transaction. It happens on two chains, requires multiple transactions, and involves an additional server type called a "witness". A bridge does not exchange assets between two ledgers. Instead, it locks assets on one ledger (the "locking chain") and represents those assets with wrapped assets on another chain (the "issuing chain"). A good model to keep in mind is a box with an infinite supply of wrapped assets. Putting an asset from the locking chain into the box will release a wrapped asset onto the issuing chain. Putting a wrapped asset from the issuing chain back into the box will release one of the existing locking chain assets back onto the locking chain. There is no other way to get assets into or out of the box. Note that there is no way for the box to "run out of" wrapped assets - it has an infinite supply. Co-authored-by: Gregory Popovitch <greg7mdp@gmail.com>
* Revert "Remove CurrentThreadName.h from RippledCore.cmake (XRPLF#4697)" This reverts commit 3b5fcd5. * Revert "Introduce replacement for getting and setting thread name: (XRPLF#4312)" This reverts commit 36cb5f9.
* For example, without this change, to run the TxQ tests, must specify `--unittest=TxQ1,TxQ2` on the command line. With this change, can use `--unittest=TxQ`, and both will be run. * An exact match will prevent any further partial matching. * This could have some side effects for different tests with a common name beginning. For example, NFToken, NFTokenBurn, NFTokenDir. This might be useful. If not, the shorter-named test(s) can be renamed. For example, NFToken to NFTokens. * Split the NFToken, NFTokenBurn, and Offer test classes. Potentially speeds up parallel tests by a factor of 5.
Remove the `verify` and `message` function declarations. The explicit instantiation requests could not be completed because there were no implementations for those two member functions. It is helpful that the Microsoft (MSVC) compiler on Windows appears to be strict when it comes to template instantiation. This resolves the warning: XChainAttestations.h(450): warning C4661: 'bool ripple::XChainAttestationsBase<ripple::XChainClaimAttestation>::verify(void) const': no suitable definition provided for explicit template instantiation request
This was likely put back when XRPLF#4292 was rebased.
Make the instructions a bit easier to follow. Users on different platforms can look for their platform name to find relevant information.
Removed the unused variable `none` from `Writer.cpp` which was causing build errors on clang version 14.
`LedgerHistory::fixIndex` returns `false` if a repair was performed. Fix XRPLF#4572
Copy the new code to `src/secp256k1` without changes: `src/secp256k1` is identical to bitcoin-core/secp256k1@acf5c55 (v0.3.2). We could consider changing to a Git submodule, though that would require changes to the build instructions because we are not using submodules anywhere else.
* Reorganize some changelog entries * Add note about portable binaries * Dev blog: https://xrpl.org/blog
Add Boost::json to the list of linked Boost libraries. This seems to be required for macOS.
gateway_balances * When `account` does not exist in the ledger, return `actNotFound` * (Previously, a normal response was returned) * Fix XRPLF#4290 * When required field(s) are missing, return `invalidParams` * (Previously, `invalidHotWallet` was incorrectly returned) * Fix XRPLF#4548 channel_authorize * When the specified `key_type` is invalid, return `badKeyType` * (Previously, `invalidParams` was returned) * Fix XRPLF#4289 Since these are breaking changes, they apply only to API version 2. Supersedes XRPLF#4577
Co-authored-by: Chenna Keshava B S <21219765+ckeshava@users.noreply.github.com>
|
@intelliot I think I made a mistake with the push, I'm working on fixing the commits. |
|
Apologies about the mess in this branch, I have cleaned up my work in this PR: #4728 |
High Level Overview of Change
Fix #4015, #4557: GRPCServer and ServerHandler are created during the construction of Application instance. Do not validate GRPC IP/Port/Protocol information in ServerHandler. Instead, pass the responsibility of grpc port information validation to GRPCServer constructor.
This ensures that configuration file can specify the port_grpc section.
Context of Change
Based on suggestions from @ximinez , I implemented this code change. @cjcobb23 suggests an alternative solution to the same issue here
I welcome any other suggestions too. I felt this is a clean way to handle this problem without breaking backwards compatibility.
Type of Change
Test Plan
I prefer to add additional unit tests such that we do not observe any unexpected behavior from configuration settings. But I'm not sure if such cases are already being covered by other unit test suites