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.
_______________________________________________
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
