External Endpoints: Token as Query Parameter

[mazzz1y]

Describe the feature request

Currently, Gatus expects a bearer token, but some apps don't allow setting it. I propose to add the possibility to pass the token using a query parameter.

Example:

# Both calls are equivalent

curl -X POST -H "Authorization: Bearer secret" https://gatus.example.com/api/v1/endpoints/endpoint_name/external?success=true

curl -X POST https://gatus.example.com/api/v1/endpoints/endpoint_name/external?success=true&secret=secret

If the maintainers are ok with this change, I can submit a PR.

Why do you personally want this feature to be implemented?

I use the FolderSync Android application. When my photos sync to network storage, it calls a webhook to check if the sync was successful.

I'm already using the HealthChecks app for this, but I want to switch to the more lightweight Gatus

How long have you been using this project?

One month

Additional information

This is not needed for me, but a similar issue can be that some apps don't support changing the request method. If Gatus also allows GET requests, it would make it much more flexible to use.

[TwiN]

I'm a little perplexed, because on one hand, this certainly makes it easier for users, but on the other hand, this isn't secure.

I'm all for making Gatus easier to use and available for as many use cases as possible, but I also have a duty to provide a secure software to my Gatus' users.

Let me think about it and see whether other people 👍 your feature request.

[mazzz1y]

on the other hand, this isn't secure.

To be honest, I don't see any security-related downsides to using secrets in query parameters. This feature is meant to be used programmatically in third-party apps, and in that case, there is little difference between headers and parameters.

[TwiN]

To be honest, I don't see any security-related downsides to using secrets in query parameters

It's not secure, because at layers from both the ingress and egress level might log the url with the query parameters, which would include the token in this case, while headers aren't usually logged.

There are certainly cases in which this is fine, like when the tokens have a short expiration duration, but in this case, the token doesn't expire.

The only reason why I'm not completely against it is that even if the token is compromised, it's not like a malicious actor can do anything too serious, outside of perhaps something that involves social engineering or phishing (e.g. pushing a failed status with an error that says visit $SOME_MALICIOUS_LINK for information on how to fix this)