There are some limitations in what we can test atm, because the v2 token trust-scoping happens at the controller level (on an existing token) rather than when issuing it. This doesn't seem to enable a representative response to be generated (in terms of the token contents) due to the way the fixtures/mocking works in these tests.
I think probably what needs to happen (under a different bug) is the trust-scoping code needs to move from the controller to where the token is generated behind the identity_api? (comments welcome on this..)
Update patch, one minor fix and added a test.
There are some limitations in what we can test atm, because the v2 token trust-scoping happens at the controller level (on an existing token) rather than when issuing it. This doesn't seem to enable a representative response to be generated (in terms of the token contents) due to the way the fixtures/mocking works in these tests.
I think probably what needs to happen (under a different bug) is the trust-scoping code needs to move from the controller to where the token is generated behind the identity_api? (comments welcome on this..)
i.e this code is never hit in these tests, but it is when you make a real request: /github. com/openstack/ keystone/ blob/master/ keystone/ token/controlle rs.py#L130
https:/
So I guess that really needs to be happening here instead? /github. com/openstack/ keystone/ blob/master/ keystone/ token/providers /uuid.py# L359
https:/
Anyway, even with the somewhat limited test, this patch should fix the vulnerability and the test does provide coverage of the new code.