You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jan 8, 2024. It is now read-only.
Is your feature request related to a problem? Please describe.
See #2136. This is the UI implementation for respecting that value. (sorry to be brief! 😅 ).
Describe the solution you'd like
I know TF Cloud has a good answer for this, so perhaps something like that to keep this feeling the same?
For example you can enter in an API token or password, and once saved, the UI will omit the value of the sensitive variable.
Note for implementors
The scope of this enhancement is strictly as follows:
Allow users to set the sensitive flag to true/false when adding/editing input variables in the UI
Hide or obfuscate the values marked as sensitive
As you undertake this work, you’ll discover that input variables managed in the UI and those defined in the waypoint.hcl file are somewhat independent of each other. The UX isn’t perfect, but try to set that aside for this particular piece of work. We’ll address it more holistically further down the road.
For now, you may wish to add some inline documentation to the UI indicating that the “sensitive” setting will only affect how the value appears in the UI, and users must make the corresponding change in their waypoint.hcl for the value to be hidden everywhere.
The text was updated successfully, but these errors were encountered:
Note that TFC has “write-only” semantics for sensitive vars, meaning the values aren’t transmitted back to the UI when rendering this page. This probably isn’t the case for Waypoint just yet.
I worked through this a little with @kitography and discovered a UX wrinkle which will probably require a change to core before we can proceed with the UI work (note video has audio):
Some extra context from @krantzinator, following on from the video above:
I think this behavior is actually OK and expected based on our current relationship between the waypoint hcl and the UI. That is, all variable definitions go in the waypoint hcl; the ui only provides values to already defined variables. “Sensitive” is part of the definition, just like the Type. So the “sensitive” mark on the UI is really just a bandaid over the fact that we don’t currently have a way for the UI to consume the waypoint hcl definition.
I agree this is a confusing UX, and this relationship has been discussed quite a bit with variables work. Maybe in addition to documentation, we could also note directly on the variable settings page “The “sensitive” setting here is for the UI only to obfuscate the value; if you want the value to be obfuscated in outputs, the sensitive setting must be defined in the waypoint hcl variable block.”
Similar to how even if you check the “HCL” box in the UI and send the value with the HCL type, if your waypoint hcl has the type as “bool” in that variable’s definition block, the user will get an error.
Is your feature request related to a problem? Please describe.
See #2136. This is the UI implementation for respecting that value. (sorry to be brief! 😅 ).
Describe the solution you'd like
I know TF Cloud has a good answer for this, so perhaps something like that to keep this feeling the same?
For example you can enter in an API token or password, and once saved, the UI will omit the value of the sensitive variable.
Note for implementors
The scope of this enhancement is strictly as follows:
sensitive
flag to true/false when adding/editing input variables in the UIAs you undertake this work, you’ll discover that input variables managed in the UI and those defined in the waypoint.hcl file are somewhat independent of each other. The UX isn’t perfect, but try to set that aside for this particular piece of work. We’ll address it more holistically further down the road.
For now, you may wish to add some inline documentation to the UI indicating that the “sensitive” setting will only affect how the value appears in the UI, and users must make the corresponding change in their waypoint.hcl for the value to be hidden everywhere.
The text was updated successfully, but these errors were encountered: