It was originally envisaged that we would allow users to specify trust
IDs in trust+*:// alarm action URLs, and only create trusts internally
when none was specified. This made storage of trust IDs in the username
field of the URL part of the API interface, and it made sense that the
user would have access to the IDs both for trusts they had created
themselves and those created internally.
However, this proved to be a security hole that was closed by
cb90d3ad472bba8d648803ca94a9196dff97f0e8, and now we forbid users from
passing in a trust ID. Any trust IDs that appear in the URL were created
internally.
This causes issues when updating alarms because aodhclient uses a
read-modify-write pattern to do so. The action URLs output from a GET
may contain trust IDs, while the input to a PUT is forbidden from
containing them. This means the data is not round-trippable, so updates
even to unrelated fields fail.
Since storage of the trust ID in action URLs is purely an internal
implementation detail at this point, scrub it out of data returned by
the REST API. This means the output of e.g. a GET will match the
original input data, as the user probably expects, and can be fed back
into a PUT successfully.
Reviewed: https:/ /review. openstack. org/564020 /git.openstack. org/cgit/ openstack/ aodh/commit/ ?id=149d3ad2193 b4d17df801f82a0 a6be62dba564db
Committed: https:/
Submitter: Zuul
Branch: stable/queens
commit 149d3ad2193b4d1 7df801f82a0a6be 62dba564db
Author: Zane Bitter <email address hidden>
Date: Thu Mar 22 17:12:43 2018 -0400
Don't include trust IDs in Alarm action output
It was originally envisaged that we would allow users to specify trust
IDs in trust+*:// alarm action URLs, and only create trusts internally
when none was specified. This made storage of trust IDs in the username
field of the URL part of the API interface, and it made sense that the
user would have access to the IDs both for trusts they had created
themselves and those created internally.
However, this proved to be a security hole that was closed by bba8d648803ca94 a9196dff97f0e8, and now we forbid users from
cb90d3ad472
passing in a trust ID. Any trust IDs that appear in the URL were created
internally.
This causes issues when updating alarms because aodhclient uses a modify- write pattern to do so. The action URLs output from a GET
read-
may contain trust IDs, while the input to a PUT is forbidden from
containing them. This means the data is not round-trippable, so updates
even to unrelated fields fail.
Since storage of the trust ID in action URLs is purely an internal
implementation detail at this point, scrub it out of data returned by
the REST API. This means the output of e.g. a GET will match the
original input data, as the user probably expects, and can be fed back
into a PUT successfully.
Change-Id: I230c0d80a9440c 7d002b9a623048e f715a9df743 8c5f5a68326d2b2 07b21e06ea)
Closes-Bug: #1737186
Related-Bug: #1649333
(cherry picked from commit 92182de328d1f08