DiamondLightSource / DiamondLightSource/blueapi
Refactor CLI login process
- Dominant language
- Python
- Stars
- 13
- Forks
- 13
- Avg merge
- 2d 11h
- Merged PRs (30d)
- 25
Description
The `login` subcommand and the supporting methods are spread across three modules (cli, client and rest). The configuration for them is split between the server (for the oidc config) and the config file (which we want the client to avoid needing (#1327)).
* To login, a `SessionManager` is created using a path from the config and queried for a token
* If it does not find a valid token, a client is created from the config (creating a new session manager from the same path)
* The client is used to get the oidc_config (via the rest client)
* The oidc config is used to create a third `SessionManager`
* The final `SessionManager` is used to start the device flow and cache the token
Without having fully worked through the repercussions, it would be good to:
* Remove the token file path from the config - we don't want to need a config file for the client
* Make the token path a CLI option if it still needs to be configurable
* Move the login method into the rest client - if we need the rest client to access the oidc config anyway, it makes sense to use it to log in.
* `interactive_login()` - to prompt the user to login
* `check_login()` - to fail early for scripts
Contributor guide
Assessment
This issue has not been assessed yet.