Open Stack

On 14/11/13 17:16, Randall Burt wrote:
> I think it could work for dashboards as well. The behavior would be to display the masked value and add a control that once activated, retrieves the unmasked value. Since one hopes this dashboard would be using some library like python-heatclient, its not that much work.

It _could_ work, especially if the control shows/hides all of the hidden 
outputs at once. I was thinking of the case where you would show/hide 
them individually, in which case trying to make use of the 2 APIs would 
lead to comically bad code. e.g.:

* Request the (possibly masked) output data.
* Display a control next to all outputs that have 'Hidden: true'.
* When the control is clicked, request the non-masked data
  - Your data is now potentially inconsistent, so maybe you should 
update all of the outputs.
* Display the non-masked data for that output. And change the data for 
all the other outputs. But not the ones marked 'Hidden', because that 
will show all of them.
* If the user clicks again, repeat this process, fetching the masked 
data again.
* Remember not to update the fields marked Hidden, except for the one 
where the click was, and the Hidden fields that are currently shown.

We could simplify this a bit:
* Request the (possibly masked) output data.
* Request the unmasked output data.
  - Your data is now potentially inconsistent, so maybe you should 
update all of the outputs, aka throw out everything from the previous, 
masked, request that you just made.
* Hide the data and display a control next to all outputs that have 
'Hidden: true'.
* When the control is clicked, display the non-masked data for that output.
* If the user clicks again, hide the data.

Which reduces to what I was suggesting:
* Request the unmasked output data.
* Hide the data and display a control next to all outputs that have 
'Sensitive: true'.
* When the control is clicked, display the non-masked data for that output.
* If the user clicks again, hide the data.

> As to there being no security value in masking sensitive data

My point here was simple: if there is a known URL from which you can 
obtain sensitive data, the existence of another known URL from which you 
cannot obtain sensitive data does not in any meaningful sense increase 
the security of the system. And that's fine if security is not the 
reason you're doing it, I'm just pointing out that I don't see any other 
reasons and security isn't one either.

>, we already have a precedent for this in parameters

We do, and consistency is nice, but simplicity of both the 
implementation and consumers' implementations is also good.

cheers,
Zane.

> without having the ability to get the unmasked values IIRC. The fact that those are user-supplied sensitive data versus system generated sensitive data is irrelevant since its the template author (which isn't always the person deploying the template) that determines a value's sensitivity, not some inherent property of the value.