CLI framework, where to store initial login session token for the following commands to use

Getting Help
1

If I have a CLI framework to login to remote network device through REST API, what are the options to store initial login session token so the following commands can using the same token to authenticate with the device?

the remote network device will need golang to authenticate first through a login-session command and it will return a token valid for 24 hours. After golang gets the token, for subsequent commands like show/post/delete, I can embed the token required the first time in these commands HTTP request header.

The above can be done by define some struct field if it’s one golang main function flow.

I’m wondering how I can achieve this using CLI, if my first command is "App connect " to get the token, how can I pass it to the following commands like “App show …”

In Powershell world, for example vmware, they can do something like "ConnectVIserver " to login to a vCenter and then subsequent commands like “get-vm” will retrieve the virtual machine information for the logged-in vcenter.

2

I’m not sure if you are asking about the internals of some specific CLI framework… or about multiple runs of your CLI tool. If the latter, one way is to put the token / API key / etc in an environment variable.

$ export token=abcd123
$ yourcli show
  ... output

If it’s produced by your program (yourcli login) and then is to be reused later (yourcli show), I’d save it in a file. Something like ~/.yourcli with the token in it, and appropriate permissions (0600).

2 Likes
3

thanks. it’s for later use case. looks like storing into a file is way to go among multiple CLI runs.

4

If you are in a position to change it, make your config a file or directory under $HOME/.config.

There is a standard around this:

$XDG_CONFIG_HOME defines the base directory relative to which user specific configuration files should be stored. If $XDG_CONFIG_HOME is either not set or empty, a default equal to $HOME/.config should be used.

The whole standard is here, but the TLDR is use $HOME/.config.

The home dir can be very busy with “dotfiles”. This is okay and most user will be used to it, but I like it when newer tools put their configs under $HOME/.config. For instance, neovim uses $HOME/.config/nvim for it’s files.

Also, if your users switch systems, it’s more likely they’ll remember to “move over” the dotfiles and configs under $HOME/.config.

Of course, this is an opinionated standard. It’s up to you.

5

Great. Thanks for this info!

6

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.