mirror of
https://github.com/reconurge/flowsint.git
synced 2026-05-07 04:09:49 -05:00
[GH-ISSUE #60] Add optional configuration options for transformers (e.g. active/passive modes) #58
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @xhzeem on GitHub (Nov 15, 2025).
Original GitHub issue: https://github.com/reconurge/flowsint/issues/60
Description:
Please add support for optional configuration options in transformers, allowing them to adapt their behavior without needing separate transformer implementations.
This would make it possible to adjust how each transformer operates — for example, running in active or passive mode, changing scan depth, setting rate limits, or enabling specific modules — while still keeping safe defaults when no options are provided.
Motivation:
Currently, transformers have fixed behavior, which limits flexibility. Many OSINT and recon workflows benefit from having configurable modes — especially for tools that can operate in both passive and active contexts.
Adding optional parameters would make transformers more powerful, modular, and adaptable across different environments (from stealth OSINT to authorized assessments).
Example use case — Crawler with Katana:
The existing crawler transformer could integrate with Katana for web crawling, and expose optional parameters such as:
mode:"active"or"passive"depth: recursion depth for crawlingjs_parse: enable or disable JavaScript parsingrate: requests per secondThis would allow users to control how aggressive or deep the crawler runs, without changing its core logic.
Example concept:
Expected outcome:
All transformers should be able to define optional configuration parameters, which are:
The crawler would serve as a model example for implementing and testing this feature.
Benefits:
@dextmorgn commented on GitHub (Nov 15, 2025):
Hey @xhzeem,
Thank you very much for this suggestion. This implies a lot of changes but it's exactly the direction we want to go !
We could make use of the
params_schemadefined in the transform base.And I very much like the "safe" behavior by default, so that we can still quickly run transforms on the go, but go deeper with fine tuning the settings.