In case we are to decommission Redis, we need to switch CentralAuth to Kask.
CentralAuth is using the store in 3 distinct way:
- To store sessions. These are set with a key 'centralauth:session' and TTL_DAY. Important note, the TTL for session data in naive sessions we just deployed is 1 hour.
- To briefly transfer data in a secure way between wikis. With centralauth, as far as I understand, your login request is redirected onto a central wiki, which, upon success, sets a token with a 1 minute TTL, then you're redirected back to your original wiki. It reads the token and transforms it into a local session.
- Additionally, centalAuth can issue API tokens, which are as well written with a 1 minute TTL. Consuming the token is done via setting a TTL to negative value. I assume this is done because of the BagOStuff interface - delete doesn't give you information on whether the item existed or not, while changeTTL does - this allows to aboid race conditions (it assumes atomicity, which BagOStuff implementations doesn't seem to completely guarantee) but in general it is indeed could be atomic, while get/delete is a clear case of a race.
Given that Kask was engineered to NOT provide the opportunity to set TTL in the request, the idea was always to create separate clusters of kask for each use-case - thus configure TTL in kask itself. Which leaves us at a crossroads: we could implement per-request TTL in kask, perhaps with a default maximum TTL, or we could split CentralAuth use-cases into 2 new clusters - for sessions and for tokens. This would require quite some coding on MW side, but nothing too crazy.
The question of consuming tokens via effectively a CAS operation is an even bigger issue, but I would like to spend some more time investigating it before making any proposals.