Allow IPv6 in Proxy settings and moving validation out from the UI into the model/ interface#430
Conversation
4f485db to
0e181eb
Compare
|
|
||
| CService serv(LookupNumeric(ipAddress, DEFAULT_PROXY_PORT)); | ||
|
|
||
| Proxy addrProxy = Proxy(serv, true); |
There was a problem hiding this comment.
As discussed offline, in the upstream repo, support to unix sockets was added (bitcoin/bitcoin#27375) already but as this repo is not refreshed and updated yet, I've created #431 and will do a follow-up on this PR once we get the feature added here.
| }); | ||
| } | ||
|
|
||
| bool NodeModel::validateProxyAddress(QString ipAddress) |
There was a problem hiding this comment.
Variable names should use snake_case, so ip_address, but maybe addr_port or even just proxy or proxy_str is a better name, especially if unix:/path/to/socket is to be accepted.
There was a problem hiding this comment.
especially if unix:/path/to/socket is to be accepted.
As explained above, unix sockets support will be addressed in a follow-up once the feature is ready in this repo.
| ArgsManager& args() { return *Assert(Assert(m_context)->args); } | ||
| ChainstateManager& chainman() { return *Assert(m_context->chainman); } | ||
| NodeContext* m_context{nullptr}; | ||
| bool validateProxyAddress(const std::string ipAddress) override |
There was a problem hiding this comment.
For consistency it would be best if the same rules apply to the -proxy= config and the text that is accepted via the GUI. For the former the validation is happening here:
and here
I am not sure how relevant the first check is for the proxy because the second check ends up calling SplitHostPort() as well. Maybe ignore the first, move the second to a new function and call this new function from the GUI and from init.cpp?
There was a problem hiding this comment.
Ok, let me do some testing on this. Thanks!
There was a problem hiding this comment.
I'm planning to refactor the init.cpp file after adding the persistence for the proxy setting, so the logic aligns with how the value is read and parsed from the settings.json file.
There was a problem hiding this comment.
I am not sure how relevant the first check is for the proxy because the second check ends up calling SplitHostPort() as wel
I’ll restore the call to SplitHostPort() as advised offline. This is necessary because, without it, LookupNumeric would apply a default port if none is provided, making an address entered without a port (like 127) appear valid. I discovered this while testing the persistence of values in settings.json (a separate PR, which is nearly finished and will be pushed ASAP). For example, if a user enters 127 in the UI, it’s stored in the file without a port. While adding a default port could work, it might not be transparent for the user.
Another point we could discuss, if necessary, in the "setting persistence" PR (coming soon today) is why an IP like 127 remains valid even when a port is specified. This is because, as discussed with @vasil during his review of bitcoin-core/gui#836, the IP validation is left to the OS (thru CService. For example, $ ping 127 results in PING 127 (0.0.0.127) 56(84) bytes of data, and this behavior aligns with how Qt and bitcoind currently handle IPs.
There was a problem hiding this comment.
Simplification idea: always require a port, from the GUI and from the command line and from the config file. Edit: the optional :port part is making it more difficult for developers while (probably) providing near 0 benefit to the users.
ba648fc to
3cb348b
Compare
|
Updates:
|
|
Just to clarify:
|
3cb348b to
ebabe49
Compare
|
Updates:
|
vasild
left a comment
There was a problem hiding this comment.
ACK ebabe49
I am not very familiar with the QML side of things, but this change looks ok to me.
Good to have in a followup: unify the checks for valid proxy from init.cpp and from the GUI: #430 (comment)
Thanks @vasild for taking the time to review this PR! I'm working already on the next PR which will have both the persistence logic of the proxy and the refactoring of the |
Allowed to configure the proxy with an IPv6 address and moved the validation out from the UI/ control to the node interface.
ebabe49 to
4dea7c9
Compare
|
Updates:
|
MarnixCroes
left a comment
There was a problem hiding this comment.
the layout breaks when you paste when the default value (127.0.0.1:9050) is still present:

this doesn't happen when first removing the default value and then pasting.
Maybe add scroll functionality to this page?
If you're not on full screen and paste and get the invalid message, the bottom of the page cannot be accessed anymore as you can't scroll down.
On desktop switching to full screen works, but it might be a bigger problem on mobile.
So simple scroll functionality is good to add to the proxy settings page.
|
Thanks @MarnixCroes. As discussed in our call among the team, both the overlapping (#437) and when the validation occurs (#438 - reverting |
|
Check out the updated web prototype to see for a proposal of how this logic could work out. |
I really like it, also the fact that the default is greyed out and it disappears when the user starts typing instead of having to delete it (I think it behaves like that currently) . Many thanks! |
| { | ||
| return std::string(DEFAULT_PROXY_HOST) + ":" + ToString(DEFAULT_PROXY_PORT); | ||
| } | ||
| bool validateProxyAddress(const std::string& addr_port) override |
There was a problem hiding this comment.
validateProxyAddress shouldn't be in this module. It should exist in the nodemodel or possibly in netbase.
There was a problem hiding this comment.
I agree, maybe it could be moved deeper into de netbase but I didn't what to touch that at this stage, it can be done later once we update the interfaces upstream.
| } | ||
| void mapPort(bool use_upnp, bool use_natpmp) override { StartMapPort(use_upnp, use_natpmp); } | ||
| bool getProxy(Network net, Proxy& proxy_info) override { return GetProxy(net, proxy_info); } | ||
| std::string defaultProxyAddress() override |
There was a problem hiding this comment.
I don't believe this should return a string. I think it should be an in/out Proxy&.
There was a problem hiding this comment.
This is just for display purposes, it doesn't make sense to build the object which also involves CService and so on, just to come back with eg ipv4.proxy.ToStringAddrPort();, I'd leave it as it is but can be done on a follow-up if more ppl think the change is required.
| virtual bool getProxy(Network net, Proxy& proxy_info) = 0; | ||
|
|
||
| //! Get default proxy address. | ||
| virtual std::string defaultProxyAddress() = 0; |
There was a problem hiding this comment.
Are these actually default settings values or just values presented to the user? If they are just hints, they can be left as strings in the QML.
There was a problem hiding this comment.
These are proper default values. I would leave them here for now, but maybe they can be moved into the netbase later.
In the prototype, the light grey text is a placeholder, not the default. We could still treat it that way if we want. |
|
tACK 4dea7c9 on Ubuntu 20.04 works as expected. |
|
Is my ACK needed on this? Looks more like a code task to me than a UI one. |
…ng validation out from the UI into the model/ interface 7bd7d1c qml, proxy: Allow IPv6 and move out UI validation (pablomartin4btc) Pull request description: The main purposes of this PR are: - Allow configure proxy server with IPv6 (after testing exhaustively in current `bitcoin-qt` [repo](https://github.com/bitcoin-core/gui/) and `bitcoind` - e.g. [IPv6 on Qt](bitcoin-core/gui#836 (comment)); [IP validation in Qt](bitcoin-core/gui#813)) - More importantly: moving the validation logic out from the UI (component/ control/ widget) into the back-end (model/ interfaces). It seemed currently in [Qt](https://github.com/bitcoin-core/gui/) all this logic (validation, network classes) was coupled to the UI since the beginning (more than [12y ago](https://github.com/bitcoin-core/gui/blame/c4443c2be141e5f45bb10376056f3083e97cde50/src/qt/optionsmodel.cpp)) instead of using interfaces (introduced much later) that would be the correct thing to do. Feedback and suggestions are very welcome and will help establish a foundation for leaving business logic out of the UI going forward. --- <details> <summary>In order to test it, if it's the first time you run <code>./src/qt/bitcoin-qt</code> you need to go thru the on-boarding flow (<i>start->next->next->next->next->connection settings->Proxy settings</i>) otherwise you need to go to the settings (top right gear icon) then <i>Connection->Proxy settings</i>.</summary>  </details> Before this change, only IPv4 address were allow in the value input, now also IPv6 can be entered. --- There are some [look and feel kind of issues](bitcoin-core/gui-qml#430 (comment)) that will be handled on follow-ups (issues: #437 and #438). ACKs for top commit: D33r-Gee: tACK [7bd7d1c](bitcoin-core/gui-qml@7bd7d1c) on Ubuntu 20.04 works as expected. vasild: ACK 7bd7d1c johnny9: ACK 7bd7d1c Tree-SHA512: f633f5729f4ca2a8433560b15722bccd5938bfa55643cd3d925b75ed01006dbc7a56fe3a20766a6bb9e2bb601c8a3828c177de3cccc7728959eb48987838e90c
See bitcoin-core#430 This code was merged into bitcoin/src in the gui-qml repository but should have been either been merged upstream into Bitcoin Core or just implemented in the GUI, which is what we do in this commit.
…ng validation out from the UI into the model/ interface 7bd7d1c36b4a1d35a399ea28d08fcca2830dfc41 qml, proxy: Allow IPv6 and move out UI validation (pablomartin4btc) Pull request description: The main purposes of this PR are: - Allow configure proxy server with IPv6 (after testing exhaustively in current `bitcoin-qt` [repo](https://github.com/bitcoin-core/gui/) and `bitcoind` - e.g. [IPv6 on Qt](bitcoin-core/gui#836 (comment)); [IP validation in Qt](bitcoin-core/gui#813)) - More importantly: moving the validation logic out from the UI (component/ control/ widget) into the back-end (model/ interfaces). It seemed currently in [Qt](https://github.com/bitcoin-core/gui/) all this logic (validation, network classes) was coupled to the UI since the beginning (more than [12y ago](https://github.com/bitcoin-core/gui/blame/c4443c2be141e5f45bb10376056f3083e97cde50/src/qt/optionsmodel.cpp)) instead of using interfaces (introduced much later) that would be the correct thing to do. Feedback and suggestions are very welcome and will help establish a foundation for leaving business logic out of the UI going forward. --- <details> <summary>In order to test it, if it's the first time you run <code>./src/qt/bitcoin-qt</code> you need to go thru the on-boarding flow (<i>start->next->next->next->next->connection settings->Proxy settings</i>) otherwise you need to go to the settings (top right gear icon) then <i>Connection->Proxy settings</i>.</summary>  </details> Before this change, only IPv4 address were allow in the value input, now also IPv6 can be entered. --- There are some [look and feel kind of issues](bitcoin-core/gui-qml#430 (comment)) that will be handled on follow-ups (issues: #437 and #438). ACKs for top commit: D33r-Gee: tACK [7bd7d1c](bitcoin-core/gui-qml@7bd7d1c) on Ubuntu 20.04 works as expected. vasild: ACK 7bd7d1c36b4a1d35a399ea28d08fcca2830dfc41 johnny9: ACK 7bd7d1c36b4a1d35a399ea28d08fcca2830dfc41 Tree-SHA512: f633f5729f4ca2a8433560b15722bccd5938bfa55643cd3d925b75ed01006dbc7a56fe3a20766a6bb9e2bb601c8a3828c177de3cccc7728959eb48987838e90c
See bitcoin-core/gui-qml#430 This code was merged into bitcoin/src in the gui-qml repository but should have been either been merged upstream into Bitcoin Core or just implemented in the GUI, which is what we do in this commit.


The main purposes of this PR are:
bitcoin-qtrepo andbitcoind- e.g. IPv6 on Qt; IP validation in Qt)Feedback and suggestions are very welcome and will help establish a foundation for leaving business logic out of the UI going forward.
In order to test it, if it's the first time you run
./src/qt/bitcoin-qtyou need to go thru the on-boarding flow (start->next->next->next->next->connection settings->Proxy settings) otherwise you need to go to the settings (top right gear icon) then Connection->Proxy settings.Before this change, only IPv4 address were allow in the value input, now also IPv6 can be entered.
There are some look and feel kind of issues that will be handled on follow-ups (issues: #437 and #438).