It's not a complete fix by any means, but i've noticed this as well and made it possible to override the value of the token_id [1] in an AccessInfo. What i intend to do is always override the value with the one that comes in from the X-Subject-Token header in auth_token middleware. There is also a patch in review to pass through a full Auth Plugin from auth_token middleware that will correctly respect this [2].
So If you correctly consume the plugin or the headers coming from auth_token middleware and use the AccessInfo object rather than parse the token content yourself it should at least not cause any problems. I don't think there is anything that we can do from a server perspective. [1] https://review.openstack.org/#/c/113415/ [2] https://review.openstack.org/#/c/107222/ ** Also affects: keystonemiddleware Importance: Undecided Status: New ** Changed in: keystonemiddleware Assignee: (unassigned) => Jamie Lennox (jamielennox) ** Changed in: python-keystoneclient Assignee: (unassigned) => Jamie Lennox (jamielennox) ** Changed in: python-keystoneclient Milestone: None => 0.11.0 ** Changed in: python-keystoneclient Status: Triaged => Fix Committed -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1328067 Title: Token with "placeholder" ID issued Status in OpenStack Identity (Keystone): Triaged Status in OpenStack Identity (Keystone) Middleware: New Status in Python client library for Keystone: Fix Committed Bug description: We're seeing test failures, where it seems that an invalid token is issued, with the ID of "placeholder" http://logs.openstack.org/69/97569/2/check/check-tempest-dsvm- full/565d328/logs/screen-h-eng.txt.gz See context_auth_token_info which is being passed using the auth_token keystone.token_info request environment variable (ref https://review.openstack.org/#/c/97568/ which is the previous patch in the chain from the log referenced above). It seems like auth_token is getting a token, but there's some sort of race in the backend which prevents an actual token being stored? Trying to use "placeholder" as a token ID doesn't work, so it seems like this default assigned in the controller is passed back to auth_token, which treats it as a valid token, even though it's not. https://github.com/openstack/keystone/blob/master/keystone/token/controllers.py#L121 I'm not sure how to debug this further, as I can't reproduce this problem locally. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1328067/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : [email protected] Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
