When MySQL is used to store revocation events, events are returned
from the database with the timestamps truncated to the second. This
causes a revocation event for a token (which has the issued_at
timestamp to the microsecond) to not match the revocation event and
therefore the token is not considered to be revoked.
The fix is to have the revocation events and token timestamps both
always be truncated to the second. This will cause all tokens for a
user that are issued within a second to be revoked when any of those
tokens are revoked, which shouldn't be a problem.
Reviewed: https:/ /review. openstack. org/111106 /git.openstack. org/cgit/ openstack/ keystone/ commit/ ?id=7aee6304f65 3475a4130dc3e5b e602e91481f108
Committed: https:/
Submitter: Jenkins
Branch: master
commit 7aee6304f653475 a4130dc3e5be602 e91481f108
Author: Brant Knudson <email address hidden>
Date: Thu Jul 31 17:47:00 2014 -0500
Fix revocation event handling with MySQL
When MySQL is used to store revocation events, events are returned
from the database with the timestamps truncated to the second. This
causes a revocation event for a token (which has the issued_at
timestamp to the microsecond) to not match the revocation event and
therefore the token is not considered to be revoked.
The fix is to have the revocation events and token timestamps both
always be truncated to the second. This will cause all tokens for a
user that are issued within a second to be revoked when any of those
tokens are revoked, which shouldn't be a problem.
Change-Id: Ibd82b4ce910206 dfd504c396614ae 2ebed025e9b
Closes-Bug: #1347961