Repository navigation
Follow-ups to #1479: ShopinBit image auth and Fact0rn Tor migration - #1493
Merged
Merged
Conversation
sneurlax
changed the title
This was referenced Nov 1, 2026
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## staging #1493 +/- ##
===========================================
+ Coverage 11.59% 11.61% +0.02%
===========================================
Files 1133 1134 +1
Lines 114059 114185 +126
===========================================
+ Hits 13223 13263 +40
- Misses 100836 100922 +86 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
julian-CStack
approved these changes
Nov 3, 2026
web3dart was handed a plain http Client, so ETH and ERC-20 RPC could not use Tor and the coin was flagged as not Tor-ready. Give it an IOClient wrapping a SOCKS5-proxied HttpClient instead, the same way Solana does it, and do the same for the node connection test. Also add the usual node tor/clearnet mismatch check and set torSupport.
Nano and Banano already send every request through Tor, and Fact0rn uses the regular ElectrumX client, so they only needed the torSupport flag. The Stellar node test proxied its first request but then created a StellarSDK with the default client, so the follow-up ledger query went out directly.
Image.network and SvgPicture.network use their own HTTP clients and ignore the Tor setting, so token logos, exchange and coin logos, CakePay card images, ShopinBit attachments and theme previews were fetched directly even in Tor mode. Add TorAwareNetworkImage and TorAwareSvgNetworkLoader, which go through the app's HTTP wrapper, and use them at all call sites.
The attachment images were fetched from a query-auth URL carrying the token and customer key. Now that they go through the HTTP wrapper, which logs failed requests, and dart:io puts the request URL in its exceptions, those credentials could end up in the log file. Fetch the plain URL with the Authorization and External-Customer-Key headers instead. TorAwareNetworkImage takes the headers but keeps keying the image cache on the URL alone, so a re-mounted attachment still comes from the cache. client.dart wasn't formatted on staging, so its diff includes one formatting change.
updateDefaults keeps the saved node's tor and clearnet flags, so existing installs kept the old clearnet-only Fact0rn default even though it now allows Tor. With Tor turned on that node is rejected and Fact0rn cannot refresh or pass the node test. Add a one-time migration that enables Tor on the saved Fact0rn default node. Only a node that still matches the old shipped default on every field the user can edit (host, port, name, SSL, failover, login, clearnet only) is touched, so a node the user customised keeps its settings. Clearnet stays enabled, so nothing changes with Tor off, and later choices are left alone.
TorAwareNetworkImage keys its cache on the url alone, so an attachment path fetched under one customer key would be served from cache to a later customer key without an authenticated request. Add an optional cacheScope that is part of the key, and pass the ShopinBit customer key there. The bearer token stays out of the key so a refreshed token does not refetch. The key is captured together with the request response rather than read from the widget when building the image: FutureBuilder keeps showing the previous snapshot while a new future is pending, and that snapshot must not be paired with a later customer's scope.
julian-CStack
force-pushed
the
pr1479/fix
branch
from
November 3, 2026 00:36
356a3b9 to
36d1f49
Compare
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
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.
Summary
Depends on #1479 and is stacked on its head (0f421bc). You can merge that then this or this and close that--kroplabeskidu's authorship of those commits is preserved either way. Until that PR merges the diff here also shows its three commits; review by commit. Please merge with a merge commit, not a squash: the history contains the #1479 head unchanged, so merging this PR alone marks #1479 merged with the contributor's authorship kept.
#1479 routes remote images through the Tor-aware HTTP wrapper and adds Tor support for Ethereum. These five commits fix the gaps that leaves.
Images
AuthorizationandExternal-Customer-Keyheaders.TorAwareNetworkImagekeyed its cache on the URL alone, so an attachment fetched under one customer key would be served from cache to a later key without an authenticated request. An optionalcacheScopeis now part of the key and the ticket view passes the customer key. The scope is captured together with the request response, becauseFutureBuilderkeeps showing the previous snapshot while a new future is pending and that snapshot must not be paired with a later customer's scope.Fact0rn
updateDefaultskeeps a saved node's tor/clearnet flags, so existing installs kept the clearnet-only node and Fact0rn would not refresh with Tor on. A v17 to v18 migration enables Tor on that node only when it still matches the old shipped default on every field the user can edit (host, port, name, SSL, failover, login, clearnet only). A customised node is left as is. Clearnet stays enabled, so nothing changes with Tor off.Ethereum
updateTransactions, the tx loop above it and the token wallet's tx loop each reuse one lazily built client for many RPCs. Toggling Tor mid-operation left the rest of that operation on the old transport. A thin client wrapper remembers whether it was built proxied, re-reads the preference on every send, and throws before sending if they disagree. It does not rebuild, reroute or retry, so a broadcast that hits the check is not sent rather than replayed on a different transport. The next operation builds a fresh client under the current preference.Not included
Verification
dart format --set-exit-if-changedclean on every changed file in each commitdart analyze lib test: no new lines versus stagingflutter test: all passed on each commitTests added
test/db_version_migration_test.dart: v18 lets the default Fact0rn node use Tor; v18 leaves an edited Fact0rn default node alone (six single-field edits)test/networking/tor_aware_network_image_test.dart: cache is scoped bycacheScopetest/wallets/ethereum_tor_proxy_test.dart: client refuses to send after the Tor preference flips in either direction, and still sends when it is unchanged