I would like to propose the following idea for consideration:
Background:
Currently, features like the telnet interface require a user’s login credentials (username and password). This means users must expose their login credentials to helper applications or scripts which might only use a limited subset of capabilities, such as monitoring alerts from the telnet gateway.
Proposal:
Support generation and maintenance of API keys with selected, limited privileges.
Examples:
Create an API key which provides (only) read-only access to read alerts via the telnet gateway. Optionally provide an expiration date for the key. Now a helper application which monitors the telnet gateway only needs the API key value, not the “full access” username/password for the account.
Misc Rambling:
Additional controls/limitations of what a given API key could do would be implementation-dependent and completely up to you. A nice, forward-thinking implementation would allow multiple API keys to be generated, each with their own limitations, expiration dates, etc. It might be overkill, but I simply thought the nature of read-only access would be appropriate for something like the telnet gateway, or any other future streaming connectivity for alerts.
Aside from the Telnet interface, there is no HamAlert API as such. The Telnet interface is a bit of an oddball thing in requiring the user’s HamAlert credentials. It started as a very niche option, so the easiest solution was to reuse the regular login credentials for the app/website. One could argue that the potential for damage by malicious applications like cluster clients etc. under the control of the user is relatively limited when it comes to the information stored in HamAlert – at least compared to what else those applications could do on the user’s computer. But what has indeed been bothering me is that using the Telnet interface exposes the user’s HamAlert credentials in plaintext to the Internet.
So I have just added the option to set a separate Telnet password on the Destinations page. This can only be used to login to the Telnet interface, not to the website or app.
This is a fantastic alternative - thank you! I just tested and confirmed it works perfectly.
A related point on APIs… For the URL Notifications - would it possible to add an optional custom parameter there for an API key? That would help prevent the possibility of noise alert injection on the receiver side. Very low risk, I know, but it might be nice to have the warm fuzzy of having a shared secret value there so the exposed endpoint on the receiver side isn’t just letting anyone inject noise.
Just to follow-up after a bit of testing – using the URL https://my.example.org/spot?key=xyz only works if GET is selected on the https://hamalert.org/destinations page as the request type. It does not work for POST. (So, if using a GET request, the additional query parameter is added - but for using POST, the additional query parameter is ignored).
At the risk of asking for both the moon and the stars it would be nice if an additional param could be added for POST requests also.
Not urgent at all, but something for a future feature perhaps?
If your server-side environment does not support parsing both query parameters and POST form data in the same request, then I would suggest simply adding some entropy to your endpoint URL to make it unguessable.
I just tested again, but gave it a good couple of minutes between saving my updated destination and running the test, and it works just fine for me as well.
but I’ll see if I can make it work.
