public function getSessionData( $key ) {
		return $this->getSession()->get( $key );
	}

and

	public function get( $key, $default = null ) {
		$data = &$this->backend->getData();
		return array_key_exists( $key, $data ) ? $data[$key] : $default;
	}

Do a get with a default of null, don't find it, so return null... So $attempt becomes null

Possibly your farm is not sharing sessions, which is a requirement for CentralAuth. Session storage configuration has changed for 1.27, you might want to review that.

In T141482#2509001, @Tgr wrote:

Possibly your farm is not sharing sessions, which is a requirement for CentralAuth. Session storage configuration has changed for 1.27, you might want to review that.

It could be possible that my configuration is not up-to-date. Like Wikimedia, we use redis for sessions (production 1.26 config):

$wgObjectCaches['redis'] = array(
	'class' => 'RedisBagOStuff',
	'servers' => array( '<IP>' ),
	'password' => $wmgRedisPassword,
);
$wgMainCacheType = 'redis';
$wgSessionCacheType = 'redis';
$wgSessionsInObjectCache = true;
$wgMessageCacheType = CACHE_NONE;
$wgParserCacheType = CACHE_DB;
$wgLanguageConverterCacheType = CACHE_DB;

I am aware $wgSessionsInObjectCache is now true by default, but that should not introduce an issue, right? I compared our configuration with Wikimedia's, and was not able to find anything that I missed.

$wgSessionsInObjectCache is ignored, session data is always stored in the object cache. The config seems fine. (Also, my previous comment was wrong - the line of code you indicated checks the normal session, not the shared CentralAuth session. It would be strange if normal login worked but CA did not.) You'll probably have to debug in more detail what happens with the session (is the session cookie correctly set? does the record with that key persist in Redis?)

@Aklapper The problem I reported could also be related to this. Any ideas on what the error could be and how it could be fixed?

I also point out we are now running REL1_28 , 1.28 and PHP 5.6.29

Just dropping by that one of the users of Polish Wikipedia recently reported a similar problem when logging in. No idea what it means though, will try to investigate.

This has been the case for nearly a year so I don't see a sudden urgency (which translates to "high priority")?
Links to reports by non-upstream users very welcome.

Note that the bug description basically amounts to "central login is not working". (Which is fair; CentralAuth is super complicated, and finding out exactly what is failing is probably the bigger part of the work. But saying "wiki X is also affected by this" as if there was a single issue affecting all WMF and non-WMF wikis, and everything could be fixed with the same debugging effort, is potentially misleading.) I don't think this task will move forward unless there is a wiki owner who can reliably reproduce the issue and is willing to do a serious amount of debugging.

Logging that User:jfsamper seems to be experiencing this issue so that I don't forget. There do not appear to be are no global locks or blocks affecting them. The user will hopefully be around tomorrow on #wikimedia-tech for further debugging effort.

For what it's worth, I can still confirm it is still happening to users on the farm.

It now looks like T169261 seems more plausible for my particular report.

I just got this error on a WMF wiki, MediaWiki.org. This is a serious issue that is obviously happening on WMF wikis as well as others and should be addressed.

@Reception123: Please see and read T141482#3284142. In genreal, "bug XYZ should get fixed!" / "me too" / "+1" comments do not bring a task closer to resolution.

I've done quite a bit of debugging downstream, and found that the issue may be T169261, but that wouldn't make sense, because we are using a version of CentralAuth that includes the fix that resolved that task. Anyway, here's the debugging I got:

Intended behavior (as seen on successful login to account Void):
Sets a minimum of ten cookies.

• Three under login.miraheze.org
  • loginwikiUserID
  • loginwikiUserName
  • loginwiki_session
• Three under meta.miraheze.org
  • metawikiUserID
  • metawikiUserName
  • metawiki_session
  • (There are others, but I believe they are irrelevant)
• Four under .miraheze.org
  • centralauth_Session
  • centralauth_Token
  • centralauth_User
  • forceHTTPS (irrelevant)

Failed behavior (as seen on broken login for Voidwalker):

• login.miraheze.org
  • loginwikiUserID
  • loginwikiUserName
  • loginwiki_session
• meta.miraheze.org
  • loginnotify_prevlogins
  • metawikiUserName

A temporary login also generates:

• meta.miraheze.org
  • UseCDNCache
  • UseDC

But those temporary cookies last less than a minute, and when they expire, so does the session. <-- Unsure of the accuracy of this statement

Following that, I took a look at my network headers and found this:

set-cookie: centralauth_Token=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; Max-Age=0; path=/; domain=.miraheze.org; secure; HttpOnly
set-cookie: centralauth_Session=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; Max-Age=0; path=/; domain=.miraheze.org; secure; HttpOnly
set-cookie: metawikiUserID=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; Max-Age=0; path=/; secure; HttpOnly
set-cookie: centralauth_User=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; Max-Age=0; path=/; domain=.miraheze.org; secure; HttpOnly
set-cookie: metawiki_session=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; Max-Age=0; path=/; secure; HttpOnly
set-cookie: forceHTTPS=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; Max-Age=0; path=/; HttpOnly
set-cookie: forceHTTPS=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; Max-Age=0; path=/; domain=.miraheze.org; HttpOnly

which mimics T168858, but again, we should have the fix for this.

Attempting to invalidate the session by resetting the password (via email) failed to both login and change the password.

Also, I just want to remark that I am concerned that my own debugging is not for the same issue as the original that we encountered, as that one could be fixed or bypassed by the user. So far, the account I triggered this on has remained inaccessible for over 24h.