nikitastupin / clairvoyance

Obtain GraphQL API schema even if the introspection is disabled
Apache License 2.0
967 stars 87 forks source link

Update README.md #26

Closed EONRaider closed 2 years ago

EONRaider commented 2 years ago

Add instructions for usage with Docker image

nikitastupin commented 2 years ago

Perfect! Thanks! 🎊

EONRaider commented 2 years ago

Glad it worked. Is the project open to contributions to the code base itself?

I think there may be a thing or two I can help with.

In fact, this tool could do more than just mapping the scheme but also proceed to exploitation.

nikitastupin commented 2 years ago

It's a privilege for me to receive your contributions and suggestions. Let's discuss your ideas! We can do it in a new issue, in Twitter (@_nikitastupin) / Telegram (@nikitastupin) DMs or even right here!

I personally favor "do one thing and do it well" approach in programming. In this way a program becomes a building block for users. Users can then use a combination of programs that fits their needs the best, without a need to implement the same thing. There are other pros as well as cons to this approach.

It was an approach I've chosen for clairvoyance (at least "do one thing" part). One can use clairvoyance for the case when Introspection is disabled, obtain a schema and then use this schema with any other tool you want.

So I see at least three options here:

Anyways I suggest to discuss your ideas and then make a decision 😃

EONRaider commented 2 years ago

That's nice. I think this one is a good approach:

* To split clairvoyance to importable module and CLI. Thus any other project can import clairvoyance as a module and benefit from not implementing the same thing from scratch.  Specifically, you may start a project that combines your ideas and clairvoyance.

It would be necessary to somehow structure the application to allow it to be pushed to PyPI as a library. With that all one would need to do is to pip install clairvoyance and use it.

This presents a challenge in architecture, though. From what I could get from the code I noticed that it doesn't have an entry point yet and it couples quite heavily the use case of the CLI to the code itself. I'll find a way around this. It's been some time since I wrote a library but I can manage it.

I'll read the code thoroughly and do a first PR just fixing formatting and maybe adding more specific function and class signatures. It's not a refactoring as it won't be intended to modify any functionality. This way I can understand each line before trying to modify anything.

In the long run, after having this tool zeroed in, we can maybe start another project that expands into exploitation too.

nikitastupin commented 2 years ago

Great! Let's try it 😄

If you'll have any questions regarding the code you can ask me and I'll do my best to provide an answer. There is also https://github.com/nikitastupin/clairvoyance/wiki/Development page that describes the project a little bit (mostly theoretical though).

I suppose there is also a quick-and-dirty way to decouple CLI and the code: we can wrap (with some modifications) this https://github.com/nikitastupin/clairvoyance/blob/main/clairvoyance/__main__.py#L77-L113 code to a function and this function together with oracle.py and clairvoyance.py will become a library. However, I'm not sure that it'll work. Moreover, it'll be really great to give my spaghetti code a better shape because it is a major obstacle to improvements (e.g. #15 was really hard to do and not yet finished).