Post-installation provider token management #450

New Issue

Open

opened 2024-02-05 13:19:27 +02:00 by inex · 0 comments

inex commented

2024-02-05 13:19:27 +02:00

Owner

Description

App communicates with APIs of three kinds:

Server providers
- Hetzner
- Digital Ocean
DNS providers
- Cloudflare
- DeSec
- Digital Ocean
Backup storage
- Backblaze

Right now:

Tokens can only be set during server installation or initial connection
They can't be changed afterwards
App doesn't detect token expiration
App expects that there are active tokens of all providers
- It should work without them when the server is deployed, but it is a part of #440 refactor
Only one token of each kind may be set

How it should be:

Tokens can be updated manually by the user
When token expires, app detects it and suggests the user to update it (or remove entirely)
Several tokens of the same kind (provider may vary) stored in the app
- Will require changes in how we store tokens in the Hive
- Will require a data migration
App knows the connection between the token and resources it manages
We need support for several tokens to implement, for example, migration between providers
When updating existing token, app has to check if the new token manages the associated resource
- Similar to logic used in server recovery

UI

There should be an "API tokens" button in the "more" section
The "API tokens" screen should show cards of each connected token
- The token itself isn't shown
- It shows the status of the token (valid/invalid)
- It shows the associations of the token with resources
- It allows to update the token or delete it
The "API tokens" should have a button to add a new token. Probably a FAB
Provider selection might look similar to how it looks like in server installation

Acceptance criteria

Stage 1

User is able to change the token of the existing provider connection

Stage 2

User is able to add and remove provider tokens
Tokens properly migrate from the old storage schema

Context and notes

Existing ProvidersController assumes there is only a single provider API key, which is used in a current server. Because right now we don't have migrations and multi-tenancy, for now it should just use the token which manages the current resource (server itself, its domain and backblaze bucket)

Closes #366

## Description App communicates with APIs of three kinds: - Server providers - Hetzner - Digital Ocean - DNS providers - Cloudflare - DeSec - Digital Ocean - Backup storage - Backblaze ### Right now: - Tokens can only be set during server installation or initial connection - They can't be changed afterwards - App doesn't detect token expiration - App expects that there are active tokens of all providers - It should work without them when the server is deployed, but it is a part of #440 refactor - Only one token of each kind may be set ### How it should be: - Tokens can be updated manually by the user - When token expires, app detects it and suggests the user to update it (or remove entirely) - Several tokens of the same kind (provider may vary) stored in the app - Will require changes in how we store tokens in the Hive - Will require a data migration - App knows the connection between the token and resources it manages - We need support for several tokens to implement, for example, migration between providers - When updating existing token, app has to check if the new token manages the associated resource - Similar to logic used in server recovery ### UI - There should be an "API tokens" button in the "more" section - The "API tokens" screen should show cards of each connected token - The token itself isn't shown - It shows the status of the token (valid/invalid) - It shows the associations of the token with resources - It allows to update the token or delete it - The "API tokens" should have a button to add a new token. Probably a FAB - Provider selection might look similar to how it looks like in server installation ## Acceptance criteria ### Stage 1 - User is able to change the token of the existing provider connection ### Stage 2 - User is able to add and remove provider tokens - Tokens properly migrate from the old storage schema ## Context and notes Existing `ProvidersController` assumes there is only a single provider API key, which is used in a current server. Because right now we don't have migrations and multi-tenancy, for now it should just use the token which manages the current resource (server itself, its domain and backblaze bucket) Closes #366