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
The
loginsubcommand 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)).SessionManageris created using a path from the config and queried for a tokenSessionManagerSessionManageris used to start the device flow and cache the tokenWithout having fully worked through the repercussions, it would be good to:
interactive_login()- to prompt the user to logincheck_login()- to fail early for scripts