Page MenuHomePhabricator

Should MediaWiki stop storing sessions on the server?
Open, Needs TriagePublic

Description

Problem
Sessions are stored on the server in MediaWiki. This means that the state of user's logged in status must be stored in a centralized location. By default, MediaWiki stores sessions in the object storage.

Proposed Solution
When a user logs in, a cookie could be set that contains a JWT. This token would contain a verified claim of the user's logged in status. This allows the session to be transfered from the client to the server on each request and prevents the server from storing the state of the user's logged-in state. This makes authorization stateless.

MediaWiki would still be able to use the existing features like "Keep me logged in."

The best way to accomplish this, might be to implement a BagOStuff for a the JWT (from the header) and perhaps extending CookieSessionProvider to set the JWT on a cookie.

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptSep 12 2019, 12:16 AM
dbarratt updated the task description. (Show Details)Sep 12 2019, 3:54 AM
dbarratt updated the task description. (Show Details)
dbarratt updated the task description. (Show Details)Sep 12 2019, 4:07 AM

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?

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).

Isarra added a subscriber: Isarra.Sep 12 2019, 3:52 PM

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?

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.

Joe added a subscriber: Joe.Sep 12 2019, 4:12 PM

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

Joe added a comment.Sep 12 2019, 4:18 PM

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.