Add support to generate API token with tanzu api-token create

[anujc25]

What this PR does / why we need it

• Add support to generate API token with the tanzu api-token create command
• Add unit tests

Sample output:

> tz api-token create 
[i] Opening the browser window to complete the login 
Log in by visiting this link: https://wdc-10-206-98-55.eng.vmware.com/auth/oauth/authorize?client_id=tp_cli_app&code_challenge=XfCGpFSLGz5x_qYhXfsjYkXpfF6865RUh32wVd20-Ys&code_challe pe=code&state=1f5e2644c6e07bf7ff00cb5064bfabbe 

Optionally, paste your authorization code: [...] 

===

API Token Generation Successful! Your generated API token is: cle82767a13748debd53e33b2d46d92b-r

For non-interactive login use the API token as follows: TANZU_API_TOKEN=cle82767a13748debd53e33b2d46d92b-r tanzu login --endpoint https://wdc-10-206-98-55.eng.vmware.com

Please copy and save your token securely. Note that you will need to regenerate a new token before expiration time and login again to continue using the CLI.

Which issue(s) this PR fixes

Fixes #

Describe testing done for PR

• Manually tests the UAA login workflow. See the above screenshot

Release note

Add support to generate API token with `tanzu api-token create` (supported for UAA as IDP)

Additional information

Special notes for your reviewer

[vuil]

Some comments about the output as I continue the review

[vuil]

looking good in general, thanks the for changes.
I have a few questions and suggestions.
And some UX output needs to be updated

[marckhouzam]

This token can only be used for UAA, correct?
If so, instead of <tanzu-platform-endpoint>, should we put something with uaa in it?

[vuil]

That UAA is used is implementation details that may be lost on many users. In a comment earlier, I suggested using terminology that is more comprehensible. Still thinking of options...

[marckhouzam]

You are right. Maybe "TPSM" is more appropriate, or the long form of it?

[vuil]

Maybe the way it is implemented is reasonable enough. Users who have to use the form "tanzu login --endpoint ..." and who has successfully use "api-token create" to get to this point should know what tanzu-platform-endpoint refers to.

[anujc25]

I have updated the log message to mention actual Tanzu Platform endpoint that needs to be used instead of <tanzu-platform-endpoint>. Let me know if any other changes are needed here.

[marckhouzam]

Nice.
Minor suggestions to take or leave.

[anujc25]

Do we know the expiration time easily?
Since we tell the user regenerate a new token before expiration, I find it nice to tell them when that will be. If not, is there another way for them to avoid their usage failing when expiration happens?

@marckhouzam regarding this, I discussed with @vuil and the conclusion is we do not have a way to know the expiration time for the Refresh Token at the moment. So, if needed we need to document the expiration time separately in the docs.

[marckhouzam]

@marckhouzam regarding this, I discussed with @vuil and the conclusion is we do not have a way to know the expiration time for the Refresh Token at the moment. So, if needed we need to document the expiration time separately in the docs.

So we will document that the token has a lifetime of X time?
Do we prefer only putting it in the docs so we can more easily change it, instead of printing the value we currently know?

I assume there is no advanced notification for the user to know the token is about to expire?

[anujc25]

So we will document that the token has a lifetime of X time? Do we prefer only putting it in the docs so we can more easily change it, instead of printing the value we currently know?

Yes. We do not know the lifetime of this refresh token at the moment. And the time can be updated without CLI's knowledge from the backend so it is safe to put that information in the docs.

I assume there is no advanced notification for the user to know the token is about to expire?

Correct, there isn't any advanced notification for the user to know the token is about to expire.

Please note that this API token generation from the CLI is a temporary workaround for supporting the non- interactive login with UAA because UAA does not have any UI to generate this token. There will be updates and enhancement in this area in future that would likely make CLI more user friendly.

[vuil]

I think we may still want to tweak the messages but the rest lgtm, thanks!

[vuil]

We may have to workshop the err/output messages in a followup. Some thoughts

• Is it better to output the token in stdout, and show the rest in stderr?
• do we want to advocate TANZU_API_TOKEN=%s tanzu login, or mention the config file way to persist the env var?

The messages in these function

• may confuse users who are interacting with the public endpoint, who ends up creating a valid tanzu endpoint and still get a surprise when this fails for him
• the instructions for regenerate and re-login might be confusing to the user of the current CLI instance (who has obviously logged in)

[anujc25]

Is it better to output the token in stdout, and show the rest in stderr?

I would prefer using stdout for both the token and the rest of the output. Since this is an output message intended for the user, it's more conventional to keep all output in stdout.