Certificate infrastructure is built on trust. If you trust the wrong thing, it all falls down. Unfortunately we do it all the time anyway.
Hey Jim YT Chen, have you tried http://httptoolkit.tech/view/ruby/ as an alternative to HttpLog? It covers a very similar use case (capturing & viewing sent Ruby HTTP), but it’s got a proper UI & tools and doesn’t require any of those code changes at all. Let me know what you think :-)
Debug all HTTP(S) sent by git, npm, apt-get, or anything else
The command line is powerful, but can be hard to understand, and extremely hard to debug. Ever run a command, see it fail with a cryptic error, and have no idea why?
Better tools can help you understand what’s really going on. They can let you see inside the command you’re running to understand how it’s communicating, see what data it’s working with, and debug it in depth.
Excitingly I’ve just shipped one-click terminal interception to do exactly this with HTTP Toolkit, for HTTP and HTTPS, to show you everything your CLI is sending and ...
HTTP View is a beautiful, free & open-source HTTP inspector. This is the first release of HTTP Toolkit, and lets you intercept HTTP or HTTPS traffic with one click, explore & examine that traffic up close, and discover exactly what your code (or anybody else’s) is sending.
Want to dive right in? Download it now.
HTTP Toolkit is a project that I’ve been working on for a while, to build an open-source suite of tools for HTTP development. The goal is to intercept & examine HTTP, edit it live, analyse flows of HTTP requests to audit performance and security, and rapidly prototype HTTP cl...
There are many ways to do this, but whatever happens, you need to change your types, as they're not correct at the moment, and you need to manually transform your result object.
The types currently say that Axios.get will return a model with Id and Name keys, which is definitely wrong (it will return a model with id and name keys). You can transform this result, but can't easily change the first return value there, so you need to correct that.
Once that's correct, you need to transform the JSON response to the model you want. One option is to use lodash, which makes this fairly easy.
A full ex...
What you're trying to do isn't possible purely in types I'm afraid. The problem is here:
new Test<A, 'id'>().create(123); // Want to get { id: 123 } That compiles to this JavaScript:
new Test().create(123); You can see it's impossible to return an object with the right key here, because your type parameter ('id') doesn't exist in the compiled code. Type information is not present at runtime.
To fix this, you need to change that design, and pass 'id' as a string parameter to either create or Test(). For example:
class Test<T extends object, TId extends keyof T = keyof T> { constru...Your best bet is to make your conditional type return true or false, and then try to assign true to the result. Like so:
type A = 1 | 2 // Must be different from B type B_OK = 3 type B_FAIL = 2 | 3 type AssertTrue<T extends true> = T; type IsDifferent<X,Y> = Extract<X,Y> extends never ? true : false type result1 = AssertTrue<IsDifferent<A, B_OK>>; // OK type result2 = AssertTrue<IsDifferent<A, B_FAIL>>; // Error You can use the new @ts-expect-error comments feature in version 3.9 on the second line to enforce that the error always throws.
If it's not appearing at all in Charles or Proxyman then it's probably not being sent over HTTP. Wireshark will show the raw TCP & UDP connections, but it's very complicated if you're not familiar with it, and there'll be a lot of info there.
One good option for this is Little Snitch. It does exactly what you want, and can show you exactly who every app is connecting to and how much traffic is sent. It normally costs $30, but they let you try it out for free, and a quick check should be all you need.
Unfortunately, Node.js doesn't listen to the http_proxy/https_proxy environment variables (see https://github.com/nodejs/node/issues/8381 for the full debate).
That means this is difficult with Fiddler - you need to change every place where HTTP requests are made to use the proxy settings, or to replace Node's default agent to do so (and then ensure no requests set a custom agent). There are some node modules that can help here, like https://www.npmjs.com/package/global-agent, but you'll also need to handle HTTPS trust separately (or you'll just see unreadable CONNECT requests, as mentioned by ...
It's also important to note that the security config file has been added to the app, but I am still getting this result.
Can you share your security config file? If that's configured to trust user-installed certificates then you shouldn't have this problem, so there may be something wrong there. Compare it with this example.
Alternatively, this might be traffic from a different app on the device. Changing the proxy settings will redirect all traffic from the device, and other unmodified apps won't trust your certificate, so will cause these exact errors.
Why are the certificates different?
The first certificate shown there is Charles's 'certificate authority' (CA) certificate. It's self-signed (note how the 'Issued By' details are the same as the certificate's details), and doesn't apply to a specific domain.
The second certificate is a certificate for a website, issued by & signed by Charles's CA certificate, with a single specific domain as its subject (not shown), and which can be used to verify a connection to that specific domain.
The way that certificate trust works is that you trust a set of CA certificates, and whenever you recei...
There's a tiny note about this in the Android 11 enterprise changelog here, which says:
Note: Apps installed on unmanaged devices or in a device's personal profile can no longer install CA certificates using createInstallIntent(). Instead, users must manually install CA certificates in Settings.
Sounds very much like this is intentional, and you won't be able to get around it on normal unmanaged devices. You'll either need to look into full Android device management, or provide instructions to your users on doing manual setup instead.
I just hit this problem in my own VPN implementation (open source, if anybody wants a working example).
In my case, this was because I was writing TCP packets back to the VPN interface that were larger than expected, because my code wasn't properly handling the max segment size.
This wasn't due to some general purpose buffer waiting to flush, so packets that were too large for the receiving application would fail with ENOBUFS forever.
Although I can't find it documented anywhere, I expect this is the cause in general: you'll hit an ENOBUFS if you try to write any packet to the VPN that's indiv...