[Feature Request] Support use of UptimeKuma API keys (UptimeKuma API keys disable basic authentication which this integration relies on)

[bladecoates]

The auth/request method, config flow, etc., must be updated to account for API Keys.

Per the UptimeKuma maintainer (0), "After you have added your first API key, basic authentication for endpoints will be permanently disabled." The Authorization header no longer uses the username field once an API Key is generated.

I updated UK last night and found the API Key page in settings and like most of us have probably done in the past. I became trigger-happy and generated a key, and saved it in my password vault for later use.

This morning I noticed the UK integration in hass throwing a 401, "Retrying setup: Request for 'https://uptime.int.home.coates.life:443/metrics' failed with status code '401" to be exact.

Some quick LOGGER.debug statements implemented in the container with a fast reload or two helped me confirm all the auth was still correct and still matched the info in my password vault, which led me to discover the above.

0: https://github.com/louislam/uptime-kuma/wiki/API-Keys

[meichthys]

Yes, This integration relies on basic authentication. This integration will break if you add API keys to UptimeKuma until the integration supports use of API keys. I don't use UptimeKuma API keys myself, so we may need a pull request to implement support for API keys.

[bladecoates]

Yes, This integration relies on basic authentication. This integration will break if you add API keys to UptimeKuma until the integration supports use of API keys. I don't use UptimeKuma API keys myself, so we may need a pull request to implement support for API keys.

I'll see if I can take a look one day this week, the way that the UK maintainer implemented ApiKeys is not the best or the ideal way. It's technically still Basic Authentication he's just omitting the "$username" part of the the auth string so instead of "$username:$password", now if an ApiKey is generated it's basically "'':$ApiKey". A separated Authorization header would have only been a couple more lines of code to implement and avoided this and many more headaches in the future.

[Selim042]

I'll see if I can take a look one day this week, the way that the UK maintainer implemented ApiKeys is not the best or the ideal way. It's technically still Basic Authentication he's just omitting the "$username" part of the the auth string so instead of "$username:$password", now if an ApiKey is generated it's basically "'':$ApiKey". A separated Authorization header would have only been a couple more lines of code to implement and avoided this and many more headaches in the future.

Were you able to find a work around or work on a PR for this? I made the same mistake today while troubleshooting and now I'm also stuck.

[katchy3132]

you can just use your user name and then use the API key as the password

[meichthys]

API Keys work fine. Just use your username and the api key as the password as @katchy3132 indicated.