The problem section doesn't explain what's problematic. It describes the current situation, where we keep sessions server-side and centralized. What's the problem with this approach?

In T232692#5486662, @MZMcBride wrote:

The problem section doesn't explain what's problematic. It describes the current situation, where we keep sessions server-side and centralized. What's the problem with this approach?

Here's a nice pro/con list:
http://www.rodsonluo.com/client-session-vs-server-session

There are, of course, ways to mitigate the cons from either list. It is a tradeoff between scalability (and reliability) and bandwidth (though the difference in cookie size is minuscule compared to the size of the page).

So what's the specific problem with regard to MediaWiki? Is this blocking something? Would it enable us to do something of particular value in our contexts here?

In T232692#5488126, @Isarra wrote:

So what's the specific problem with regard to MediaWiki? Is this blocking something? Would it enable us to do something of particular value in our contexts here?

I think the problem (in my mind) is that MediaWiki is storing state on the server, that isn't necessary to store. In other words, it creates a scalability and reliability hurdle that, when removed, simplifies the infrastructure needed to run MediaWiki.

In T232692#5488146, @dbarratt wrote:

In T232692#5488126, @Isarra wrote:

So what's the specific problem with regard to MediaWiki? Is this blocking something? Would it enable us to do something of particular value in our contexts here?

I think the problem (in my mind) is that MediaWiki is storing state on the server, that isn't necessary to store. In other words, it creates a scalability and reliability hurdle that, when removed, simplifies the infrastructure needed to run MediaWiki.

What do you mean by "MediaWiki is storing state on the server"? I think that statement is incorrect. At least as far as the WMF installation is concerned.

Storing session state on server side (whether in memcached or whatever) instead of as an encrypted blob on the client has lots of upsides

• Its much harder to screw up from a security perspective
• You are not tossing around large blobs (I assume in this proposal everything in $_SESSION would be stored as an encrypted JWT token?)

I'm not really aware of any significant scalability concerns that would justify backing away from these upsides, but the ops aspect of session storage is not an area I follow too closely

In T232692#5488179, @Bawolff wrote:

Storing session state on server side (whether in memcached or whatever) instead of as an encrypted blob on the client has lots of upsides

• Its much harder to screw up from a security perspective
• You are not tossing around large blobs (I assume in this proposal everything in $_SESSION would be stored as an encrypted JWT token?)

I'm not really aware of any significant scalability concerns that would justify backing away from these upsides, but the ops aspect of session storage is not an area I follow too closely

If we're talking server-side sessions vs client-side sessions in general, there is no real scalability problem we have with storing and retreiving server-side sessions in production.

The current code does not assume that the client can handle cookies (e.g. when it authenticates via OAuth). So this would either break all clients with no / incorrect cookie handling, or require all state to be removed from non-cookie-based requests (e.g. T126257: The API should not require CSRF tokens for an OAuth request).

We'd also have to rethink our approach to manual session invalidation.

In the end it would be fairly pointless for Wikimedia and other MediaWiki installations which rely on some kind of SSO as they would still need to store some global, cross-domain session on the server side.