You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
importdiskcachedef__query_with_cache(target: str, config: Config, cache_dir: str='./') ->Optional[dict]:
# Check if private IP or notifis_private(target=target):
__debug(f"The target IP is in private range: {target}")
returnNone# Create path for cache if not existsifos.path.exists(cache_dir) isFalse:
os.makedirs(cache_dir, 0o700)
__debug("Opening cache")
withdiskcache.Cache(directory=cache_dir) ascache:
# Enable stats if not enabled on the first runcache.stats(enable=True)
# Expire old items firstcache.expire()
__debug("Checking cache")
cache_result: Optional[str] =cache.get(target) # type: ignoreifcache_result:
__debug("Found the value in cache")
returndict(json.loads(cache_result))
else:
__debug("Cache miss. Querying APIs...")
# Initiate resolverresolver=Resolver(target, config)
# Fetch dataresolver.fetch()
# Get resultexport=resolver.export()
ifexport:
__debug("Adding the response to cache")
cache.add(target, json.dumps(export, sort_keys=True))
else:
returnNone
To make the code above understandable, I must give some context. I had to make wtfis a library that outputs JSON results for that integration. So, the external script can just call the library methods. I, first, stripped away all the UI related code, then created a wrapper class called Resolver, which includes the generate_entity_handler method inside. Then a fetch and an export method were added as the main interface to the library.
In wtfis you used environment variables stored in .env.wtfis file. In order to be able to integrate smoothly, I first created a class called Config, that I can pass to Resolver. One can use any method to create this Config class. In my case, Wazuh initiates the Python script with a bash script, along with arguments. So, I read the arguments, initiate the Config class instance, and pass it to the Resover along with the target IP or domain name.
These two methods are the interface of the wtfis library. Everything else was moved under wtfis.internal.
The code above then reads the SQLite-backed cache. I am using the defaults for cache settings. But it is possible to customize parameters, choose a different strategy, and have a shorter lifetime for cache.
The idea is to minimize the API usage. It may help in the long term.
The text was updated successfully, but these errors were encountered:
Hey @zbalkan , this is awesome! Really cool how you were able to repurpose wtfis! :)
I think this is a good idea, but my concern is mostly the additional overhead in maintaining this feature. Some questions that come to mind:
Does this require a major refactor to accommodate the caching feature?
Can this be an optional feature (at least for now), where the user needs to explicitly enable it? And ideally also modular so that if there is a bug in caching, it won't affect wtfis as long as caching is turned off.
How much additional work (if any) is needed every time we add a new data source, compared with if there was no caching feature
It will be a major refactor. Not too hard but it would be difficult than my current solution. Because, I export the json in the end. So, I have a single point to read and write. But in existing wtfis code, UI is also involved. In many places. There must be multiple points to read and write to cache. Still it's doable.
I suggest to keep caching optional too.
In each client, there must be a method to check the cache. And if there's no result (cache miss), the client will run as it does right now. But, the response must be written back to the cache again. It should not be much work. To make the cache accessible, I consider writing a singleton, so that each client will have access via a standard interface.
Testing is hard but not too complex. Let's see. I can start working on a POC in mid-Aprill.
I used this solution in my wtfis-Wazuh integration and it works smoothly.
To make the code above understandable, I must give some context. I had to make
wtfis
a library that outputs JSON results for that integration. So, the external script can just call the library methods. I, first, stripped away all the UI related code, then created a wrapper class calledResolver
, which includes thegenerate_entity_handler
method inside. Then afetch
and anexport
method were added as the main interface to the library.In
wtfis
you used environment variables stored in.env.wtfis
file. In order to be able to integrate smoothly, I first created a class called Config, that I can pass toResolver
. One can use any method to create thisConfig
class. In my case, Wazuh initiates the Python script with a bash script, along with arguments. So, I read the arguments, initiate theConfig
class instance, and pass it to theResover
along with the target IP or domain name.These two methods are the interface of the
wtfis
library. Everything else was moved underwtfis.internal
.The code above then reads the SQLite-backed cache. I am using the defaults for cache settings. But it is possible to customize parameters, choose a different strategy, and have a shorter lifetime for cache.
The idea is to minimize the API usage. It may help in the long term.
The text was updated successfully, but these errors were encountered: