-
Notifications
You must be signed in to change notification settings - Fork 101
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support android-arm64/Termux #57
Comments
Oooh interesting. You'll probably also have issues with node-datachannel due to this revert although hopefully we should be able to fix that soon. I'm not really sure what the error is complaining about above though. It's some issue with running install steps for @sentry/cli, but it's not clear what exactly has failed or why, as far as I can see. You may be able to fix this by just uninstalling that dependency - it's only used to send sourcemaps to Sentry for debugging later when bundling the server for deployment with webpack, it's probably not relevant for any usage outside the official package. |
Thanks for those tips!
to the Error log
Sadly, I'm now at a point where I'm lacking experience to get around these myself. I am uncertain if that's the last issue either, since I'm still just trying to |
Hmm, yes, if you can't
I would test the build with some different node versions, and then if that doesn't work open an issue with node-datachannel to either expand prebuilds or help you with your build error. |
@pimterry btw why does the HTTP toolkit need a node-data channel? The read me says WebRtc, but why would the HTTP toolkit need webrtc support Looks like this package always creates issues. |
Because HTTP Toolkit also supports WebRTC 😄. HTTP & WebRTC are very often used together, and so it's necessary if you want to be able to fully debug any P2P web applications. Similar reasoning to why we now support WebSockets. If you want to test it out, try launching an intercepted Chrome window, opening https://webrtc.github.io/samples/src/content/datachannel/channel/ in two different tabs there, clicking 'Start', then sending some messages back and forth. You should see the connections and data channels appear in HTTP Toolkit. It's still a bit experimental, but it should work for all simple cases and quite a few more complex scenarios, and it's really useful for pages that are communicating via WebRTC!
The main issue here is just that the build was setup wrong I think, and so the update to include arm64 support here had to be reverted. On x86 or on M1 if you use Rosetta (which I think should work automatically?) everything should work just fine I think. The built app definitely works everywhere AFAIK, it's just local dev that's tricky. I do want to fix this though, to make sure local dev on M1 devices works correctly. You'll be excited to hear that I've just bought an M1 Mac Mini specifically to work on this, so hopefully I should be able to bring new improvements here soon! 😄 |
Update: Unfortunately,
That's again a known issue at termux/termux-packages#10868. Maybe you have an idea how to workaround it? EDIT: And even then, intercepting the response doesn't work because it doesn't trust any upstream certificates. Might because of the root environment, but I'm not sure. Termux isn't configured as intercepted in the HttpToolkit app at least. |
Hmmm, both of those issues (trusted certificates & os.networkInterfaces) seem like problems with Termux's node package, not something solvable here I'm afraid. For the Regarding the certificates, the server (via Mockttp) delegates this almost entirely to Node, so this means that Termux's node build isn't correctly populating the certificates there. Mockttp usually uses the values from tls.rootCertificates as the base certificates to trust, so you can test this yourself by launching node manually and running You should also test this by using the |
Thanks for the reply. I've checked the
Could it be that the injected HttpToolkit system certificate is causing this issue, even for apps that aren't intercepted? Maybe it would work to explicitly ignore the injected system cert instead of failing here. |
Ah, so to be clear, you're running HTTP Toolkit on an Android device, and then you're intercepting that device with HTTP Toolkit too? That will almost certainly not work by default, as you'll end up intercepting outgoing upstream traffic from HTTP Toolkit back via HTTP Toolkit itself again, and end up in a loop. Even before that though, you'll find that the loopback connections fail with certificate errors, since HTTP Toolkit doesn't trust itself for upstream connections (and shouldn't - this shouldn't ever normally happen!). That would explain this: it's not an issue with the real upstream certificate at all, it's a trust issue with HTTP Toolkit's own self-signed certificate, which obviously isn't in Node.js's default trusted certificates. Are you using HTTP Toolkit's Android app to handle interception? If so, you may be able to fix this by changing the settings in the app once you're connected, to disable interception for all apps except the real target you're interested in (i.e. disabling interception of Termux). If that's not correct, can you explain more details about your setup, and exactly what you're trying to do? |
Yes, the idea is to capture the traffic from other apps running on the same device without requiring an external PC. There are other apps for Android that can do this, but those suffer from the user CA restrictions and are simply not as good as HttpToolkit. I'm using the HttpToolkit server within Termux and use the app.httptoolkit.tech web UI in Vivaldi Browser. Then, I connect to the locally running "wireless" adb which connects to the HttpToolkit Android app and injects the system certificates. I have nearly all apps unchecked in the app's settings, including Termux and Vivaldi, so those should not be (and aren't) captured. However, the injected system certificates still cause upstream requests from the server Termux to fail. This surprises me, since those requests shouldn't be intercepted nor signed with the self-signed certificate. It seems, to me, that node doesn't trust the whole chain due to the self-signed certificate. No idea why, unfortunately. |
If I understand the linked Termux issue correctly, it's caused by Android's privacy lockdown that prevents apps from accessing interfaces to not be able to query the hardware mac address, which could be used as a user identifier. Thus, it would be up to the app(s) to handle this correctly. I personally don't find that very realistic, and would also suggest a patch to node, but again, not really knowledgeable in that area and don't really know what the best solution would be here. |
It would be cool to be able to run the httptoolkit server directly on device inside Termux.
Right now,
npm install
fails with the following trace:2022-09-25T09_56_35_396Z-debug-0.log
The text was updated successfully, but these errors were encountered: