yahoo-eng-team team mailing list archive

[Jamie Lennox <jamielennox@xxxxxxxxxx>]

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