Add API Keys Support

[natterstefan]

Hi @Dean151,

once again, thank you for creating a replacement for the deprecated and now offline API for our pet feeder devices. I'm playing with your API, and I can't wait to see the final Deployment section in the README to set this up in my local network.

Until then, I've another feature request that's gonna be helpful when using the API with Smart Home Buttons like the AWS IoT Button and others: API Keys.

Feature Request

• add endpoint which allows creating API keys
• add endpoint which allows deleting API keys
• API keys can be used to use the feeders/{id}/feed and feeders/{id}/planning endpoint

I ask for API keys as I am unsure how long the authentication token is valid without me updating IoT button requests again and again.

Thank you very much!

[Dean151]

Seems like a reasonable ask. API keys are way less secure than renewable jwt (and I don't even know myself how many time they're stay valid either) ; but my pick would be less than 24h. I'll also add an option to customize this token validity threshold.

[Dean151]

Just for the sake of it, your IoT button can trigger any script? If so, you can also create a password to your account, and then use that password to authenticate ; then trigger the meal in your script ; and wire that to the IoT button. I'm proposing that because usually the good practice for API keys is that they are to be used to authenticate and obtain an expirable token to be used then for the real thing.

[natterstefan]

I'll also add an option to customize this token validity threshold.

Thank you, I can't wait to see how one can deploy your solution in the own home network.

Just for the sake of it, your IoT button can trigger any script?

Good questions. It has been a while since I set up the button. But I quickly checked and yes it triggers a lambda function on AWS which runs node. So technically, I could do some more requests than just the one triggering the feed endpoint.

I'm proposing that because usually the good practice for API keys is that they are to be used to authenticate and obtain an expirable token to be used then for the real thing.

Yeah, you are right. Makes sense.

So this is the sequence of requests, correct?

POST user/reset (create password)
POST user/reset/consume (get a token)
POST POST feeders/{id}/feed

And I need to do this every time I hit the button because the token expires. 👍

Question though: what's the difference for you compared to API keys in that regard? I need a key (email+password) to obtain one that expires to get to the result I want. My code still needs to know the secrets (email+pw in this case). It's the expiration factor, isn't it? 🤔

[Dean151]

I would say that the process would be two step:

1. Manually create a password

   POST user/reset (ask for a one time login token)
   POST user/reset/consume (consume one time login token ; provide an authorization token for next steps)
   GET user/me (get your user id)
   PUT user/<id> (update your password)

2. In your script (with password)

   POST user/login (get an authorization token using email/password)
   POST feeder/<id>/feed (trigger a meal)

Later, with the API token it'll be something like:

POST user/token/consume (use API token to get authorization token)
POST feeder/<id>/feed (trigger a meal)

[natterstefan]

Hi @Dean151,

just for the record, I want to confirm that steps 1 and 2 work flawlessly for my use case but require a server/serverless endpoint available somewhere. It's not a big deal with Vercel, for instance, though.