Custom HTTP Notification -> API Secret should not be required if API Key is used

[TimmiORG]

What?

Currently Graylog requires a API secret in case API key is used.
But the AbuseIPDB API does not require the API secret.
https://docs.abuseipdb.com/#introduction

Please remove the dependency of the API secret so that API Key could be used without it.

Why?

I'm trying to push events via the new custom HTTP notification feature of Graylog 6.0 to AbuseIPdb.com.
https://community.graylog.org/t/graylog-6-custom-http-notification-abuseipdb/32396/3

Your Environment

• Graylog Version: 6.0.1
• OpenSearch Version: Elastic Search 7.10.2
• MongoDB Version: 6.0.15
• Operating System: Rocky Linux 9.4
• Browser version: FF 125

[kingzacko1]

Hi there, @TimmiORG. Maybe the intended purpose of the API Key and Secret fields isn't quite clear. The API Key field is intended to be the name of the query parameter or header that the API on the other end is expecting your key to be in while the API Secret field is your actual API key. To take an example from the AbuseIPdb API you've linked:

curl -G https://api.abuseipdb.com/api/v2/check \
  --data-urlencode "ipAddress=118.25.6.39" \
  -d maxAgeInDays=90 \
  -d verbose \
  -H "Key: YOUR_OWN_API_KEY" \
  -H "Accept: application/json"

In this case, your notification API Key field should be set to Key and API Secret would be set to YOUR_OWN_API_KEY. Here is that example shown with a test notification in my Graylog setup with the API Key and Secret sent as a header and as a query param.

If we were to remove the requirement that they both be provided together, your header/query param would be empty Key: or Key= which I do not think would be useful and I don't think I see any use cases in the documentation you've provided. If it was necessary though, you could simply add the header manually to the Headers field as seen here.

Let me know if that makes sense or if I'm missing a valid use case for the empty value in the documentation you've referenced!

[TimmiORG]

Hi @kingzacko1 ,

thank you very much for the good explanation. This clarifies it very well.
So I guess we can close this ticket than.

[kingzacko1]

@TimmiORG you're welcome! I will go ahead and close this one out. Let us know if you run into any other issues and I'll be happy to take a look!