reuse valid token
Now if we call the auth API with the same authentication information, the keystone will always return a new token. This behavior sometimes will bloat the token table with valid tokens when the auth API is called too often and the expiration time is long.
This BP tries to reuse the same token when the existing token has the same scope as the expected new one. We try to reuse the existing token if the expiry time is within a scope ( threshold). We will not change the reused token's expiry time, i.e. we return the old token as it is.
the IRC discussion logs:
https:/
Blueprint information
- Status:
- Complete
- Approver:
- None
- Priority:
- Undefined
- Drafter:
- None
- Direction:
- Needs approval
- Assignee:
- yong sheng gong
- Definition:
- Superseded
- Series goal:
- None
- Implementation:
-
Unknown
- Milestone target:
- None
- Started by
- Completed by
- Morgan Fainberg
Related branches
Related bugs
| Bug #1215627: Keystone Should re-use non-expired tokens, instead of generating new tokens. | Invalid |
Sprints
Whiteboard
what if my token is about to expire and i want a fresh one?
yong sheng gong said: I think we can allow 'admin' role to have this privilege to have a fresh new one token with specific API parameter. The system reuses the token according to the threshold value for normal user API access.
Sean McCully <email address hidden>:
Hi Yong Sheng,
Just wanted to follow up on this Launchpad bug, not sure if you've already knocked it out. But this is roughly a rough draft of how I think it would be implemented. No pressure to use any of my code or anything, just thought I would put it out there.
https:/
yong sheng gong said: https:/
it seems the client has done with it via keyring.
(morganfainberg): I'll post this here as well, it's copy-paste from the bug #1215627:
This seems like the wrong approach. If a token is meant to be re-used the client (be it the python-*client OS provides or something else) should use it. New authentication should result in a new token (regardless of storage of said token on the backend). Re-issuance of the same token is a bad idea and breaks with the general direction we are trying to go with having truly ephemeral tokens.
