Separate Token Revocations from the Token Backend
Token revocations should be permanant, but it is ok if tokens themselves are ephemeral. THey have different lifespans and should be in separate backends.
It will address https:/
Blueprint information
- Status:
- Complete
- Approver:
- None
- Priority:
- Medium
- Drafter:
- Adam Young
- Direction:
- Needs approval
- Assignee:
- Morgan Fainberg
- Definition:
- Superseded
- Series goal:
- None
- Implementation:
-
Not started
- Milestone target:
- None
- Started by
- Completed by
- Adam Young
Related branches
Related bugs
Sprints
Whiteboard
Icehouse 1
Why not just deprecate the memcache token backend in favor of dogpile caching to (for example) memcache + sql backend? -Dolph
Dolph, that doesn't solve the problem of cleaning up the tokens. Even if both token store and trl uses dogpile, the tokens should still be memcache backed and the revocation list stored in something non-ephemeral, sql or otherwise.
I don't follow the concern regarding cleaning up tokens - can you elaborate? With dogpile, you'd get non-ephemeral persistence for both (via SQL) and backing to memcache (or redis, or whatever) without any additional complexity. The existing memcache token driver can be deprecated and removed. -Dolph
Having the Revocation list split out from the Token Driver means that the token driver store can be totally ephemeral. There is no guarantee that dogpile will be stable storage. The idea would be to split this functionality out into something that allows tokens to be stored ephemerally (aka. memcached) without affecting the stability of the revocation list. That is to say, until we can deprecate the need for a revocation list (long term plan). There is a BP to deprecate the memcache driver and replace it (and KVS) with a dogpile store (so more interesting backends such as cassandra et al could be used). -- Morgan
superceded by https:/
