Last modified: 2014-01-10 18:26:05 UTC
ImportSession doesnt seem to actually import the session data if using native php session support. Furthermore, in that case it seems to delete the existing session, changing the users tokens (which can be annoying) Given we already have to store request info to make this scheme work, im not sure why we don't just store this info in the db (or even just in memcache if something more ephemeral is wanted.)
Yeah, RequestContext was built so that code could create new contexts and build the output for certain requests (like special pages inside parser outputs and maintenance scripts dumping offline versions by creating contexts for pages and grabbing the output). It was NOT built to allow cli scripts to access sessions attached to requests made from the browser. If this chunked upload job stuff wants to work with data attached to some session. Instead of using RequestContext it should create some class were some new session id is setup, a container is registered inside of either a cache or the database. And the browser session gets an id telling what one of those cache/db containers is being used. Then the job works with the data that is put into that container for it's use. After that I think we should delete RequestContext::exportSession and RequestContext::importScopedSession.
As an additional comment, im not overly a fan of storing ip addresses in the db for purposes such as this if it can be avoided.
Hmm, now its not working even though I'm using $wgSessionsInObjectCache = true;
Change 72473 had a related patch set uploaded by Brian Wolff: Have Chunked upload jobs bail if cannot associate with session. https://gerrit.wikimedia.org/r/72473
Turns out this was (at least for me) due to suhosin.session.encrypt being turned on, which encrypts the session based on the IP of the user.
Change 72473 merged by jenkins-bot: Have Chunked upload jobs bail if cannot associate with session. https://gerrit.wikimedia.org/r/72473
