I have used it already on two apps and the results are good enough to write an alternative client or quickly automate some stuff.
On the same note, I wrote a program to generate Python code (requests) from a HAR capture: https://github.com/louisabraham/har2requests
I think using HAR captures is simpler for the end user than spawning mitmproxy as they don't require any installation and are extracted from the network tab of the browser devtools. Is there a reason why you didn't use them?
EDIT: I realized that mitmproxy can also get traffic from other devices like phones. Very cool project, I will think about modifying mine to support mitmproxy captures!
[1]: https://github.com/captn3m0/ideas#openapi-specification-gene...
I was able to translate HAR to OpenAPI with this web site's free preview: https://www.apimatic.io/transformer/
I also see others are working on the same thing: https://github.com/dcarr178/har2openapi
[1]: https://github.com/koxudaxi/fastapi-code-generator
[2]: https://github.com/ioxiocom/openapi-to-fastapi
[3]: https://infosecwriteups.com/hail-frida-the-universal-ssl-pin...
If you're really intent on getting it to work, downloading the binary, patching out the verification function and putting it back is also possible if you're root.
[1]: https://frida.re/docs/android/
[2]: https://mobsecguys.medium.com/exploring-native-functions-wit...
Roughly speaking: WSDL is to XML web services as OpenAPI is to REST
They both model the API and message structure of an API. AFAICT WSDL goes a little farther in that you can declare message sequences (I might be giving short shrift to OpenAPI here).
I'm looking for a generic tool to build and then serve:
Accept Incoming request (API contract A) Send outgoing request (API contract B) potentially with parameters from the incoming request Receiving incoming response (API contract B) Do some translations/string manipulation Send outgoing response (API contract A)
For example, you can expose mitmproxy, listen to HTTP requests for a specific host (using this API: https://docs.mitmproxy.org/stable/api/mitmproxy/http.html), intercept the request, do whatever API calls you need, and inject a response without ever forwarding the request to the original server.
Alternatively, you could modify the request and then change the request destination, like in this example here: https://docs.mitmproxy.org/stable/addons-examples/#http-redi.... Using the WSGI support, you could even use normal Python annotations to build your own API without doing too much pattern matching: https://docs.mitmproxy.org/stable/addons-examples/#wsgi-flas...
Mitmproxy solves that by being between the client and server and injecting it's own self-signed certificate (which you need to add to the trusted certificates on the phone, which requires root).
I feel liken the next step is automatically generating load tests and/or fuzzing tests. Felt like that could be a real product.
This is a challenging task and we don't support OpenAPI v3 specs yet (we are working on it).
Feel free to have a look, and get ideas from it :)
We'll also be presenting it at next Kubecon 2022.
Even just documenting an SSO flow as a diagram would be quite neat.
https://everything.curl.dev/usingcurl/copyas#:~:text=From%20....
When it works, it's effing magic! Spectacular for very quickly knocking out Bash scripts that test multiple APIs.
However, many apps apply cert pinning in production builds, which will require tools like Frida to disable them, which in turn requires root access/a jailbreak to function.
Alternatively, you could pull the apps from your phone without root (at least on Android), patch the most obvious cert pinning out (usually in the network manifest file) and install the new version.
We're having hundreds of undocumented endpoints created over the years, and running this tool on our backends will create instantly good documentation
Thanks for that! Will give feedbacks if any issues
This would come in very handy for codebases where an OpenAPI v3 spec would be welcome, but is too onerous to create by hand. Run this for a bit, have it spit out a nearly complete spec, and tweak it a bit to output the final product.
In fact, it is precisely what we did to generate the OpenAPI docs for NodeBB [1]. We had an undocumented API that we turned into an OpenAPI v3 file.
step 2: features for training a language model on the request and response variables in the mitm stream and a shim for standing up a fully ml data driven zero code mock backend.
