Prompt for Lagoon Variable

[tnelson-doghouse]

Is your feature request related to a problem? Please describe.
When people add password variables using the Lagoon CLI, they have to type the password on the command line.

Describe the solution you'd like
The Lagoon CLI will prompt you to enter a value for the variable, and not echo it as you type

Describe alternatives you've considered
None

Additional context

Possible ideas include:

• Prompt for a value if none is given, or at least if someone passes --value-prompt true
• Allow a --value-prompt secret option that makes it not echo anything at all

Possibly should be a security bug instead of a feature request.

HTH,

[shreddedbacon]

The problem though is that not all variables are passwords or secrets.
Will have to have a think about this a bit.

[tnelson-doghouse]

Oh, agreed. That's why my plan is that we use the --value-prompt as follows:

• Not specified -- current behaviour
• Matches /^(secret|hidden)$/ -- treats it as a password/secret
• true -- treats it as a non-secret, but will prompt for the value

HTH,

[shreddedbacon]

Oh, agreed. That's why my plan is that we use the --value-prompt as follows:

• Not specified -- current behaviour
• Matches /^(secret|hidden)$/ -- treats it as a password/secret
• true -- treats it as a non-secret, but will prompt for the value

HTH,

Can you show how you think this would work with a complete command line example please

[tnelson-doghouse]

$ lagoon add variable --project master-project --environment staging --scope runtime --name MY_PASSWORD --value-prompt secret
Please enter the value:
success!

In the example above, the value was entered but not echoed. While it's traditional for programs like SSH not to accept passwords on STDIN, this might be a case where the password should be accepted on STDIN.

$ lagoon add variable --project master-project --environment staging --scope runtime --name MY_VARIABLE --value-prompt true
Please enter the value: Hi!  I'm a value
success!

In the second example, above, the value "Hi! I'm a value" was entered, and is visible at the prompt. This is visible because --value-prompt was not "secret" or "hidden". It may be that it should've rejected it for containing invalid characters; if so, feel free to adjust the example so it doesn't.

The third case I won't give an example of, because it's just using --value instead of --value-prompt, and things working the way they do now.

HTH,

[shreddedbacon]

Yeah, I don't know about this whole prompt switch thing like that.

If this was going to be something we support, I would have --value-secret or --value as the only supported flags. and you provide one or the other.

The --value-secret flag would prompt you to enter the secret like you suggest while hiding the input, while --value would require the user to use the cli as they do now.

Like this then:

lagoon add variable --project master-project \
  --environment staging \
  --scope runtime \
  --name MY_VARIABLE \
  --value-secret
Please enter the value:
success!

And then the default behaviour

lagoon add variable --project master-project \
  --environment staging \
  --scope runtime \
  --name MY_VARIABLE \
  --value "my value"
success!

If a user did something like this, it would have to ignore the --value-secret flag.

lagoon add variable --project master-project \
  --environment staging \
  --scope runtime \
  --name MY_VARIABLE \
  --value "my value" \
  --value-secret

[tnelson-doghouse]

Not 100% what I wanted, but definitely close enough to keep me happy :) . Satisfies the security requirement, and I can add my own scripting for the non-secret case.

I'd suggest a warning in the last case, when both options are specified.

HTH,

[shreddedbacon]

Not 100% what I wanted, but definitely close enough to keep me happy :) . Satisfies the security requirement, and I can add my own scripting for the non-secret case.

I don't see a reason to have hidden|secret|true as the prompt if you're wanting to protect the stdin and one of the options still makes the input visible. If the idea is to keep them "secret" then why even bother having a prompt that still displays it as plain text in the prompt? It is also more work and logic to have the individual cases to support hidden text and visible text and I think makes it more complicated over all.

I'd suggest a warning in the last case, when both options are specified.

Warning why? When the user presses enter in the case both are specified its going to run the command and perform some work. So the act of trying to preserve the secret is already lost in that case.

[tnelson-doghouse]

• For the purpose of protecting STDIN, you're right, you don't need the other options. It was more a convenience for the user, but thinking about it more, it's probably not as useful as I thought it might be.
• The reason I suggest the warning is because it means that someone made a mistake. For a single run, that's not a problem, but if that mistake has eg. been pasted into documentation, or is used in a script, then it'd be nice for people to know about it. I mean, still change the variable and be successful, but let people know that the --value-secret flag was ineffectual.

HTH,