cli icon indicating copy to clipboard operation
cli copied to clipboard

Unhandled exception when renewing login from a different Cognito user pool

Open victorlin opened this issue 2 years ago • 1 comments

Current Behavior

# Start local nextstrain.org server

# Log in to the testing Cognito user pool
export NEXTSTRAIN_DOT_ORG=http://localhost:5000
export NEXTSTRAIN_COGNITO_USER_POOL_ID="$(jq -r .COGNITO_USER_POOL_ID ../nextstrain.org/env/testing/config.json)"
export NEXTSTRAIN_COGNITO_CLI_CLIENT_ID="$(jq -r .OAUTH2_CLI_CLIENT_ID ../nextstrain.org/env/testing/config.json)"
nextstrain login

# Attempt re-authentication against the production Cognito user pool, which fails with output below
unset NEXTSTRAIN_DOT_ORG NEXTSTRAIN_COGNITO_USER_POOL_ID NEXTSTRAIN_COGNITO_CLI_CLIENT_ID
nextstrain login

Output is an unhandled exception:

Traceback (most recent call last):
  File "runpy", line 196, in _run_module_as_main
  File "runpy", line 86, in _run_code
  File "nextstrain.cli.__main__", line 43, in <module>
  File "nextstrain.cli.__main__", line 19, in main
  File "nextstrain.cli", line 36, in run
  File "nextstrain.cli.command.login", line 101, in run
  File "nextstrain.cli.authn", line 165, in current_user
  File "nextstrain.cli.authn.session", line 615, in verify_tokens
  File "nextstrain.cli.authn.session", line 631, in _verify_id_token
  File "jwt.jwks_client", line 108, in get_signing_key_from_jwt
  File "jwt.jwks_client", line 99, in get_signing_key
jwt.exceptions.PyJWKClientError: Unable to find a signing key that matches: <kid>

Expected behavior

Output is an error message with instructions to remediate.

Possible solution

Catch the PyJWKClientError and throw a NextstrainCliError with a meaningful message. Example:

Unable to verify existing session. Please re-authenticate using
`nextstrain logout` and `nextstrain login`.

Your environment: if running Nextstrain locally

Nextstrain CLI version 7.4.0

Additional context

I think real users will only ever have access to one user pool, so this seems developer-facing. That stays the case even with #333 where it'd be one user pool per remote. However, if a user happens to edit their secrets file directly, that can cause a similar unhandled exception.

victorlin avatar Dec 15 '23 00:12 victorlin

I think real users will only ever have access to one user pool, so this seems developer-facing.

In this case it'd be helpful to not only provide instructions to remedy (great!) but also a possible explanation as to why this happened.

jameshadfield avatar Dec 15 '23 01:12 jameshadfield