Closed execveat closed 1 year ago
Refactoring & decoupling is needed to make parser properly testable. Might as way publish it as a separate library at that point.
We're going to drop support for the standalone mode in the next release, so the standalone Python library will also be an alternative to those using InQL as a standalone CLI tool. Finally, using a library for parsing will make it easier to find (or write) a Kotlin replacement for it.
The initial work has been done for this already, by the way in https://github.com/doyensec/inql/tree/dev branch
Refactoring & decoupling is needed to make parser properly testable
I don't get it. If the code is decoupled in a module, it should be testable, whether there is a library (another repository) or not. As of now, you can install inql and import the parser modules separately.
We're going to drop support for the standalone mode in the next release
Standalone mode is used for real by people not having BURP and makes the tool usable by people not in computer security. https://github.com/doyensec/inql/issues?q=is%3Aissue+standalone+is%3Aclosed
It should be possible to distribute a fat-jar that includes both Jython/Kotlin and be standalone.
Nit. it's possible BURP will not operate good with multiple extensions having Jython loaded multiple times, 'cause of library/import name clashes.
Right now the parsing code is located in utils.py
and generators/
, where it's intermingled with other functions. For the purposes of e2e testing, inql.generators.query.recurse_fields is the best function we could use, but its results still need additional parsing & formatting and inputs require complicated setup.
Compare that with new library (from https://github.com/doyensec/inql/tree/dev/python/gqlpy) where I can do:
from gqlpy import GQLSchema
schema = GQLSchema('https://.../graphql')
schema.generate_sample_queries()
This isn't the final API, we need a way to import JSON, iterate over queries & mutations and pass parameters to generated queries. But it's clearly much nicer way of both testing and reusing this functionality.
As for standalone mode, long term plan is to rewrite extension in Kotlin. As such, there is no plan to support standalone GUI due to maintenance overhead. I don't think there is a good use case for that either and it's not ergonomic at all. There will be a CLI version which will be a separate project, as a tiny wrapper around the new GraphQL parsing library.
Once the library gets stabilized, I'll rewrite it in Kotlin and the existing version will be bumped to Python 3 to live as a separate project.
What's the use for refactoring out the standalone library? The UI side is not big enough to grant a standalone project wrt the library.