workaround .env file

[g4ze]

We at intelowlproject/IntelOwl#2107 (comment) are trying to implement an analyzer of phoneinfoga . For this, we deem it unsuitable for our framework to put in api the API keys in the .env file. Instead, it could be feasible if we can pass the api key with the request to the endpoint itself and not have it picked from the .env file.

[sundowndev]

Hi @g4ze, this could be solved by the introduction of scanner options which is basically adding support for optional parameters for existing scanners. This could be quickly implemented without breaking change and used through the API like this:

curl -X 'POST' \
  'http://localhost:5000/api/v2/scanners/numverify/run' \
  -H 'accept: application/json' \
  -H 'Content-Type: application/json' \
  -d '{"number": "33679368229", "options": {"api_key": "secret"}}'

If it's not specified, the environment variable is used. Could you confirm that this would solve your case?
Thanks

[g4ze]

Thanks for the attention! So you basically you mean that we'd need change https://github.com/sundowndev/phoneinfoga/cmd/scan.go
a bit, in a way to have ScanCmdOptions struct include another variable? I'm not too fluent with golang but maybe i can try to raise a PR and add the functionality if you like.
And yes the addition of optional parameters for existing scanners, and using it through the way you mentioned would solve my use case.

[sundowndev]

No I'm talking about the REST API only, not the command line. If I understand correctly, you plan to integrate phoneinfoga in your project by using the REST API, is that right?

For this we'll need to change the scanner interface here to accept those options. If this can wait a week or so I can take care of the changes.

[g4ze]

my bad. yes, you understood our problem well. We can wait a week or so. Please keep us updated for the same.

[sundowndev]

@g4ze I just released v2.11.0 which contain this new feature. Please give it a try and send us feedback. Read docs here.

[g4ze]

works as requested, thankyou very much

[sundowndev]

Cool! After reviewing your PR, I suggest that you use a fixed docker tag, instead of using the latest tag (here) because it could lead to breaking change when we release v3 for example. You can use the v2 tag as well.

Anyway, I can close this one.

[g4ze]

hmm, makes sense. Thankyou for the suggestion :3 !