Requests for comment/SessionStorageAPI

This is a request for comment for a multi-master session storage service interface.

Background
Ideally, sensitive data in Mediawiki would be isolated to limit the impact in the event of a compromise. Sessions are a good example of this; Were a malicious user able to obtain arbitrary session data, they would be able to hijack other user's sessions (including for example, those of admin users). In Mediawiki, these sessions are stored using a (configurable) BagOStuff implementation, specifically a RedisBagOStuff in the Wikimedia production environment. While this does provide some isolation, it remains possible to enumerate sessions if an attacker were able to obtain a reference to the Redis connection object. Storing sessions to an external service that exposes a narrow API, nothing more than required to store, retrieve, and delete sessions, safeguards against this type of exposure.

Additionally, a need has emerged for sessions to be global; In order to realize our objective of being active-active, sessions created in one data-center should be available in the other. Accomplishing this in a robust and secure way will require replication semantics more sophisticated than those available to us with Redis.

This document proposes an implementation of a key-value storage service, with master-master replication, for use in multi-DC session management.

Versioning
A global version that follows the principles of semantic versioning is proposed. Backward-compatible changes to representations, and bug fixes will fall under minor and patch changes respectfully. Changes to the major are reserved for backward-incompatible (read: breaking) changes. Every effort will be made to avoid breaking changes, however should they become necessary, a major-version prefix in the URI (e.g. ) will provide the means to preserve compatibility during a transition.

Information regarding major, minor, and patch changes will be maintained in a source controlled changelog. Meanwhile, support for older versions will be maintained until use has fallen under a certain threshold. Once use has fallen, there will be an implementation of Sunset header to notify users that the endpoint and/or versions will become deprecated.