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.
Conflicts:
keystone/tests/test_v3_os_revoke.py
Change-Id: Ibd82b4ce910206dfd504c396614ae2ebed025e9b
Closes-Bug: #1347961
(cherry picked from commit 7aee6304f653475a4130dc3e5be602e91481f108)
Reviewed: https:/ /review. openstack. org/112087 /git.openstack. org/cgit/ openstack/ keystone/ commit/ ?id=6cbf835542d 62e6e5db4b4aef7 141b1731cad9dc
Committed: https:/
Submitter: Jenkins
Branch: stable/icehouse
commit 6cbf835542d62e6 e5db4b4aef7141b 1731cad9dc
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.
Conflicts:
keystone/ tests/test_ v3_os_revoke. py
Change-Id: Ibd82b4ce910206 dfd504c396614ae 2ebed025e9b a4130dc3e5be602 e91481f108)
Closes-Bug: #1347961
(cherry picked from commit 7aee6304f653475