What to do about Subscribed Applications?

[dmcomm]

• It's an extra setup step that's really easy to forget.
• It doesn't really add any security because the app ID isn't a secret.
• Now people can create multiple API tokens, give one to each app, and revoke them if needed.

[dmcomm]

• Ability to suspend API tokens and restore them later?
• Include name of API token in the MQTT request sent to device?
• Some sort of log on webapp so you can see which token was misbehaving?

[mechawrench]

Thoughts on this are to do the following:

• Simple list of apps and one button intitial "Get API Key"
  - This key will be easy to type "horn-rocket-egg-bucket..." with whatever separator character that will cause the least amount of issues (see w0rld encrypted vars)
  - Ability to pause an application without "unsubscribe", exclusivity mode to remain a feature
  - Ability to rotate (renew) an App API Key
  - Ability to delete a key

• Device UUID - same deal, we don't need an actual UUID, it can be something simple to type. It isn't even private necessary, just the API key is.

• User UUID to remain the same, there is no input of this anywhere except the secrets.py file that is downloaded from the site.

• App ID - Thinking on this, it probably is not necessary at all with this new method of issuing an API Key per app like you said. It was used for me to identify on the backend a few things, and to ensure subscription status

Logging events is tricky, I can do so but the question remains should this log persist forever? Should it be stored in the database, in the cache?

[dmcomm]

See #11