Problematic login behavior for scripting/automation on Windows

[abeyerpath]

I'm opening this more for visibility of the issue and discussion than suggesting a specific change at this point...there may be several things related to this that would be worth considering.

The behavior that I'm seeing is that in certain circumstances when the login command is invoked from a headless/background script on windows it attempts to do a console prompt for a password that fails (since we don't have a console), but then fails to exit with a non-zero return code, so the script continues running as if it had succeeded.

This is particularly problematic given that the current session is not cleared on failure of a login attempt, and we could have another session marked current that is still valid, and the script would then continue executing any other force commands against the wrong account/environment.

So some thoughts on potential changes/fixes that I think might be helpful:

1. Make sure failed logins always return an error code. I strongly suspect this is a platform issue in the speakeasy library, but haven't dug into it yet...so probably needs an upstream fix or something local to work around it.
2. I think it would also make sense to clear the current session on login failure as well. Leaving a previous one active after the user has attempted to change it seems dangerous. This might be a breaking change if anyone relies on the current behavior of falling back on a previously logged in session.
3. Cached credentials are not my favorite approach for automation scenarios at all. I'd like an option to provide credentials with each command and ignore the cache, for use in this type of situation.
4. Failing that, an "--all" option to logout would be helpful, to at least make sure a script starts from a blank slate. Currently to do this you have to either loop over a list of logins or kludge it by blowing away the cache files directly.

I'd welcome any feedback or thoughts on this, and if there are specific items that are agreed on, I'll likely have a bit of time coming up to put in some PRs.

[abeyerpath]

Hey @cwarden , had you seen this? Any thoughts on approaches and/or what you would consider a PR for?

[cwarden]

Not exiting with an error code does seem to be Windows-specific. Seems to be ok on linux:

$ force login -i test -u test@example.com  <&-
Password: stty: 'standard input': Inappropriate ioctl for device
stty: 'standard input': Inappropriate ioctl for device

ERROR: failed during password entry: read /dev/stdin: bad file descriptor
$ echo $?
1

I'd be happy to take a pull request to fix this.

I don't like clearing the current session upon login failure since you can explicitly logout prior to login if that's what you want.

Adding the ability to pass credentials for all commands seems useful, but ideally it would work with JWT authentication as well.

You could also set the HOME environment variable to a temporary directory. HOME is supported on windows and unix. Or you could delete the credential cache directory before invoking force.

[cwarden]

The --account flag can now be used with all commands to ensure that the right session is being used, and to fail if a session isn't available for that user.