API key support

[Scrin]

In some cases it would be useful to be able to poll some of the apis (such as the /history and /metrics endpoints) programmatically without having to disable authentication, for which I think having a configurable api key would be the best.

Suggestion: a user-configurable apikey which can bypass the auth wall for the "api endpoints" by supplying it as a bearer token, for example:

curl -v -H"Authorization: Bearer apikeygoeshere" http://gateway.ip.or.hostname/history

[ojousima]

We'll need to consider the security implications, I think that the API key would be readable by every user of the WiFi. Something like SHA256(username + password) might be doable

[Scrin]

Actually for that reason I'd prefer having a distinct, configurable api key that has only read-only access to certain API's since the traffic is plain http anyway. A malicious user can indeed sniff the key from the network traffic, and if it's a simple hash of username + password, it's prone to bruteforcing the username + password which can then be used to configure the gateway.

Though a SHA256(username + password + salt) with long enough salt that can't be determined externally would work though, but I'd still prefer a user configurable key (blank by default which would disable it)

[TheSomeMan]

@laurijamsa , @ojousima could you please check if the new UI is ok?

[ojousima]

The UI should have a short description, e.g. "Store this token securely if you want to use the configuration interface programmatically".

Having it under advanced settings is good in my opinion

[TheSomeMan]

[ojousima]

UI looks good. Finnish does not have a really good translation as far as I know, let's use:

[X] Käytä API-tunnusta
API-Avain
[FIELD_WITH_API_TOKEN]
Tallenna tämä tunnus turvallisesti, jos haluat käyttää määritystoimintoja ohjelmallisesti.

@Scrin Do you agree with the above translation?

The bearer token is unencrypted, but since it is used only over assumed-secure LAN that should not be a problem. Security-sensitive information such as passwords are not sent back through configuration interface if I have understood correctly.

In theory someone could update the gateway firmware to steal the stored information, such as remote server passwords, but the Gateway isn't meant to be used in high-security environments where attacker has the skills to create custom firmware to steal data.

[Scrin]

I'd translate the api key as api avain, since it's a key, not really an identifier (tunnus), also since we're talking about the configuration interface, I'd rephrase it to "hallintaliittymä". I'd also include the detail that this is a bearer token more clearly in the wording, so that advanced users know how this token is supposed to be used (as bearer token is normally used in the Authorization header, as shown in my example in the original issue post above) without having to look up the documentation. I'd also rephrase "Use" as "Enable", since this is enabling a new way to authenticate, not replacing the existing way. There is no official translation for the bearer token as far as I know so I'd keep it in English in the Finnish translation as well

My suggestion:

[X] Enable bearer authentication
API key (bearer token):
[FIELD_WITH_API_TOKEN]
Store this token securely if you want to use the configuration interface programmatically.

[X] Ota käyttöön API-avain
API-avain (bearer token):
[FIELD_WITH_API_TOKEN]
Tallenna tämä avain turvallisesti, jos haluat käyttää hallintaliittymää ohjelmallisesti.

[ojousima]

Thank you for the comments @Scrin , @TheSomeMan let's use Scrin's suggestions