This is a new task to support the Leak-Lookup (I'll just refer to it as LL below) service, which contains breach data.
It works off the LL API, and support the usage of both types of keys:
Public: free, but rate + daily request count limited and it only gives a source, but no details about breach data details
Private: one has to pay for it, but then the API provides actual breach data details
As mentioned above, the task configuration accepts both types of API keys, the place in the task where the difference will be seen is the linked issue creation:
public_api_key_proof_message = "No detailed breach data is shown when using public keys"
response["message"].each do |result_key, result_value|
_create_linked_issue("leaked_data", {
name: "Entity found in Leak-Lookup (Public Breach Data)",
source: result_key,
proof: result_value.empty? ? public_api_key_proof_message : result_value,
references: [
{ type: "description", uri: "https://leak-lookup.com"}
]
})
end
There is also a weird behavior I encountered, sometimes we randomly end up with a successful response from the LL service, but the body is empty, while that shouldn't happen:
# No idea if this is a Typhoeus::Request lib issue, or just a Leak-Lookup side one, but
# we can encounter successful responses with empty bodies
if (response.body).empty?
_log_error "Got an HTTP response with an empty body from the Leak-Lookup service. Please run the task again."
return
end
My current solution for that is to halt the execution of the task, and it will need to be ran again. This might not be ideal, especially if we want this task to be ran as part of a brand monitoring workflow, where we expect every task to finish successfully as we run then in batches.
This is a new task to support the Leak-Lookup (I'll just refer to it as LL below) service, which contains breach data.
It works off the LL API, and support the usage of both types of keys:
As mentioned above, the task configuration accepts both types of API keys, the place in the task where the difference will be seen is the linked issue creation:
There is also a weird behavior I encountered, sometimes we randomly end up with a successful response from the LL service, but the body is empty, while that shouldn't happen:
My current solution for that is to halt the execution of the task, and it will need to be ran again. This might not be ideal, especially if we want this task to be ran as part of a brand monitoring workflow, where we expect every task to finish successfully as we run then in batches.