feat: auth token / API key option

[kirmar]

This PR supports a --momento-api-key option for all CLI commands (except configure). If specified, the --momento-api-key overrides the one retrieved from the --profile (or the default profile).

Huge thank-you to @tylerburdsall for the additional suggestions and use cases to expand my implementation!

Purpose

Easier to verify the scopes of temporary tokens and to test functions that require a vended, specifically formatted token. We no longer need to configure a separate Momento profile for quick tests.

Verification

1. Usage Example: invoke function that requires metadata-embedded token

In token-vending-machine from the Momento Function examples, add invocation permission:

        )
        .with_function(
            FunctionPermissions::invoke()
                .with_all_caches()
                .with_all_functions(),
        );

After you build web-function-token-metadata and your updated token-vending-machine into $FUNCTION_EXAMPLE_WASMS, put them to a $MOMENTO_PROFILE with a normal, console-generated API key (super user v1 or owner v2, whatever you have handy):

cargo run -- preview function put-function --profile $MOMENTO_PROFILE --wasm-file $FUNCTION_EXAMPLE_WASMS/token_vending_machine.wasm --name get_token

cargo run -- preview function put-function --profile $MOMENTO_PROFILE --wasm-file $FUNCTION_EXAMPLE_WASMS/web_function_token_metadata.wasm --name token_metadata

Finally, confirm that token_metadata can be invoked with your $MOMENTO_PROFILE endpoint/cache and a temporary API key:

cargo run -- preview function invoke-function --profile $MOMENTO_PROFILE --name token_metadata
# {"message":"No metadata provided, try invoking with a Momento key that was generated with a populated 'token_id' field"}

TMP_MOMENTO_TOKEN=$(cargo run -- preview function invoke-function --profile $MOMENTO_PROFILE --name get_token | jq -r '.api_key')

cargo run -- preview function invoke-function --profile $MOMENTO_PROFILE --momento-api-key $TMP_MOMENTO_TOKEN --name token_metadata
# {"message":"Token metadata provided: my very secret value"}

2. Usage Example: checking temporary token's scope

cargo run -- cache set --key TheAnswer --value 42 --profile $MOMENTO_PROFILE --momento-api-key $TMP_MOMENTO_TOKEN
# TODO kira is working on this

cargo run -- cache create --profile $MOMENTO_PROFILE --cache foo

cargo run -- cache set --key TheAnswer --value 42 --profile $MOMENTO_PROFILE --momento-api-key $TMP_MOMENTO_TOKEN --cache foo
# [no response = success]

3. Rejection Verification: configure --momento-api-key

Because configure acts differently (guides the user through creating a new profile with API key/token, endpoint, etc. instead of using an existing profile/token/endpoint), I decided to leave its implementation as-is and have it reject the --momento-api-key option.

As seen below, configure hides the otherwise-global --momento-api-key help text and fails if it's still specified:

cargo run -- preview --help
# ...
# Options:
#       --verbose
#           Log more information
#   -p, --profile <PROFILE>
#           User profile [default: default]
#       --momento-api-key <MOMENTO_API_KEY>
#           API key to use when interacting with Momento, instead of using your profile's API key
#   -h, --help
#           Print help

cargo run -- configure --help
# ...
# Options:
#       --verbose               Log more information
#   -p, --profile <PROFILE>     User profile [default: default]
#   -q, --quick                 
#   -a, --api-key-and-endpoint  Overwrite credentials by providing an api key v2 and endpoint
#   -d, --disposable-token      Overwrite credentials by providing a disposable auth token or legacy v1 api key
#   -h, --help                  Print help

cargo run -- configure --momento-api-key abc
# ERROR: --momento-api-key should not be provided. You will be prompted for your API key.

Usage Note

If you specify the --momento-api-key for any command other than invoke-function and with a token generated differently than above:

base64-encode the API key with your endpoint, either in your token vendor or as follows (Thank you, @kvcache and @tylerburdsall!):

TMP_MOMENTO_TOKEN=$(echo '{"endpoint": "$MOMENTO_ENDPOINT", "api_key": "'$TMP_MOMENTO_TOKEN'"}' | base64 -w0)

[tylerburdsall]

Looks good so far! We discussed offline regarding details, looks like it would be great to apply this new global override to all the available commands, along with centralizing the actual credentials provider logic since that seems to be inconsistent across commands. A great new feature nonetheless, can't wait for this to ship 💪

[kirmar]

TODO add similar logic to all commands that use the args.profileand credential_provider, per @tylerburdsall's comment. (Totally forgot to do this, thanks for catching that!)

[kirmar]

TODO if possible, centralize the credential_provider logic to be shared across all commands, per @tylerburdsall's comment

[kvcache]

yeah, seems like you'd want to source the auth token in get_creds_and_config and/or authenticate. That way the credential provider still provides the credential!

(particularly relevant because the argument is marked global)