Change Details

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.

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.

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.