v3.10.0

Description

Adds a tags option to the createrole cli function. The format for the tags input can be either JSON or a shorthand syntax (different from the shorthand for other function inputs) and is handles by the unpackTags utility function. a Tags object is created and passed to alks.createRole

Rally # US805874

Type of change

• Feature (non-breaking change which adds functionality)

How has this been tested?

Unit tests were added to capture most conceivable input cases forunpackTags.

*Note* I think the ts type system change involving unknown types not falling under the any umbrella is surfacing in the 'errorAndExit` code. I'll try to find more information later.

Steps:

1. npm test

Checklist / To Do:

• Write documentation reflecting the change
• find more info on the uknown types and mitigate any issues
• implement errorAndExit in unpackTags

v3.9.2

Fixes a bug brought up by Jayson Parrott in the #alks-client-support channel where running alks developer configure would always skip the prompt for default output format

v3.9.1

Fixes a bug with storing/retrieving the password from the os keychain. Prior to this, the password was being stored under alkspassword but retrieved from alksuid, effectively making it impossible to update your password in the keychain. I don't know how nobody else has had issues with this yet

v3.9.0

Adds the --non-interactive flag so that you can pre-/configure individual fields when running alks developer configure.

The request for this feature is coming from the need in the arf-core repo to be able to configure a credential-process for the ALKS cli while keeping all other user settings (by copying the ~/.alks-cli/ folder into a docker container). However, I believe this feature will also serve other use cases since I've seen usages where people try to preconfigure the CLI by setting the ALKS_SERVER, ALKS_USERID, and ALKS_PASSWORD environment variables, but now they will be able to do this without needing to set environment variables

v3.8.0

closes #230
closes #231

As requested by @psmith6, this provides a way to bypass alks opening up the token management page by allowing you to directly pass in your token by piping it through STDIN. Since this change was made for MFA token authentication I figured it was only fair to extend it to basic username/password authentication as well.

I liked the idea of allowing users to pass their tokens easily through CLI args and I had already started working on this exact feature a couple weeks ago but unfortunately discovered it's fairly unsafe since it leaks credentials to any other process on the user's machine. This article does a decent job explaining this reasoning if you want to read more. As an alternative, I made this PR on top of the changes you provided so that you can still configure the cli via a oneliner by piping your credentials like this as long as all the other necessary options are provided:

echo 'your-refresh-token' | alks developer configure \
    --server 'https://alks.coxautoinc.com/rest' \
    --username bwatson3 \
    --account '012345678910/ALKSAdmin - awstest123' \
    --role Admin \
    --auth-type refresh-token \
    --output env

and you can also set only your refresh token via

echo 'your-refresh-token' | alks developer login2fa

but keep in mind for this command the cli will still need you to have already set a server url so that it can verify the refresh token works, so you'd need to make sure you had either already configured the cli with alks developer configure ... or set the ALKS_SERVER environment variable

Piping credentials in this way is more safe than specifying them via cli args and doing so will cause ALKS to skip the logic where it opens up a browser window with the token management page

v3.7.4

This PR fixes a spacing issue with the Docker creds output

v3.7.3

Adds a forced timeout for checking for updates against NPM (since the timeout we configured for the package that we use to query NPM doesn't always work). Also removes Google Analytics tracking since we never use it

v3.7.2

Fixes the following bugs related to the automatic migration of the alks.db file:

• moves the logic for ensuring that the ~/.alks-cli directory is created into its own function so that it can guarantee the existence of the directory before trying to move or read files in that location
• re-adds support for the ALKS_DB environment variable for specifying a custom path for the alks.db file (which was broken by a recent update) to support legacy use cases

v3.7.1

…n with a generous try-catch

Should fix the issue that Kenneth Studer brought up in the alks-client-support channel

v3.7.0

fixes field names for some github actions