Login or session problems (such as not being able to log in, immediately getting logged out, randomly getting logged out, not being able to edit due to "loss of session data" errors) can be caused by a large variety of things, which makes debugging them hard.

When investigating or reporting errors, here are a few tips.

• If the problem is being unable to login because of "There seems to be a problem with your login session..." errors, clearing all cookies for that site usually helps.
• When making a bug report, always include what browser (and what version of it) you are using, whether you are using it in incognito mode, and whether you are using non-default privacy/security settings (such as "block third-party cookies").
  • If possible, include a precise date and time of when you experienced the problem, so it can be correlated with system logs.
• You don't have to do an in-depth investigation just to file a bug report, but if you do want to, here are some kinds of information that are usually helpful:
  • Does it persist after clearing cookies for the wiki domain? When logging in using incognito mode? When logging in with a different kind of browser?
  • If you use any ad blockers or browser privacy add-ons, are they blocking anything? Does it work if you turn them off?
  • Does it affect multiple user accounts, or just one?
  • Does the "remember me" flag make any difference? (Clear cookies before attempts.)
  • If the problems are happening on a Wikimedia wiki, try logging in on another wiki, preferably one that does not share a second-level domain name (so if the problem happens onxy.wikipedia.org, try for examplexy.wiktionary.org).
  • If the above information is not enough to diagnose the issue (which is usually the case), you might be asked to get detailed debug data. For that, you need to capture the relevant HTTP requests and responses (i.e. visiting the login page + submitting the login form + the resulting redirect; if the wiki uses single sign-on then all the requests toSpecial:CentralLogin andSpecial:CentralAutoLogin as well). This can be done by using theNetwork tab in theDeveloper Tools of your web browser (more information:Firefox;Internet Explorer,Chrome and Chromium,Safari).Dumping to a HAR file is an easy way to log all required data.
    • Note that this includes security-sensitive data (such as your session ID); when sharing the information as part of a bug report, you need touse a private paste (privileged access for developers). You are encouraged to remove your password from the report (in the case of a HAR file, you can just open it as a text file, search for the password and replace it with something else) and to log out and log back in afterwards.

When debugging the default MediaWiki login, look for the following things:

• On Special:Userlogin, does the website set the<wikiID>Session cookie? Is the cookie sent back correctly when the login form is submitted? Does the cookie value persist during multi-step login (e.g. 2FA)? Does the session exist in the backend (you can check withObjectCache::getInstance($wgSessionCacheType))->get("MWSession:$sessionCookieValue"), usingshell.php).
  • If you are debugging an API-based login, the cookie should instead be set by the response tometa=tokens and returned in theaction=login request. Clients failing to do this is the most common source of login errors. (Note that the best practice for bots and similar clients is to useowner-only consumers and not use login at all.)
• After a successful login, are the<wikiID>Session,<wikiID>UserName,<wikiID>UserId,<wikiID>Token cookies set (the last one only when the "keep logged in" checkbox was used)? Do theuserId /userName /userToken fields match in the data stored in the backend? Does the token match the value ofuser.user_token in the database?
• If you want to check things with a debugger likeXDebug, for session/cookie problems the interesting parts tend to be theprovideSessionInfo() method of the session provider (usuallyCookieSessionProvider), andSessionManager::loadSessionInfoFromStore. For problems with processing the submitted login request, it'sAuthManager::continueAuthentication() and thegetAuthenticationRequests() andbeginPrimaryAuthentication() methods of the primary authentication provider (by defaultLocalPasswordPrimaryAuthenticationProvider). Note that these are pretty complex codebases and will be hard to understand if you aren't familiar withSessionManager and AuthManager.
• See also the advice about logging in the next session.

When debugging CentralAuth (e.g. Wikimedia sites), the things to look for:

• On top of the normal cookies, there should also becentralauth_Session,centralauth_User and (with the "keep logged in" option)centralauth_Token (typically set on the parent domain). These should be enough to recreate the other cookies when those are missing. The session cookie corresponds to the central session; its data can be checked withMediaWiki\MediaWikiServices::getInstance()->get('CentralAuth.CentralAuthSessionManager')->getCentralSessionById($sessionCookieValue) (usingshell.php). The token corresponds toglobaluser.gu_auth_token in CentralAuth's shared database.
• After a successful login, there should be a chain of redirects toSpecial:CentralLogin/start →Special:CentralLogin/complete → back to the initial page (orreturnTo target). The /start step sets up a stub central session, and sets cookies for the central domain; the /complete step finalizes the central session, and sets cookies for the local domain. (See phpdoc inSpecialCentralLogin for a more detailed description.) Are the cookies emitted as expected? Does the browser actually persist them? Is the data stored in the central session backend correct? If this step doesn't work, edge login / autologin won't work either.
  • The "keep logged in" flag (ie. thecentralauth_Token cookie) is set in a separate step, by a request to Special:CentralAutoLogin/refreshCookies that's triggered from an‎<img> tag when the rest of the autologin is finished. Are the cookies emitted? Does the browser actually persist them? When this step doesn't work, edge login / autologin will stop working when the central session expires in a day or so.
• Right after central login, edge login is triggered: For every wiki in$wgCentralAuthAutoLoginWikis, there is a redirect chain to various Special:CentralAutologin subpages (/start → /checkLoggedIn → /createSession → /validateSession → /setCookies) via an image embedded in the page. The setCookies step should create a local session and set the session cookies. Are the cookies emitted? Does the browser actually persist them?
• When visiting a wiki where you do not have an active session (and no shared cookies on the parent domain to create one), central autologin is triggered. This is basically the same as edge login, just in a script tag instead of an image tag, and the same things should be verified.
  • When central autologin fails, further attempts are prevented by setting theCentralAuthAnon localStorage flag; you might need to clear that when testing.
• When visiting the login page while not having an active session, top-level autologin is triggered. This is basically the same as normal autologin, just with the whole page being redirected, instead of an embedded image doing the redirects, and the same things should be verified.

There's anoverview of CentralAuth authentication features available.

• Check what session backend is being used ($wgSessionCacheType), and make sure it works (data is actually persisted between requests). The most safe configuration is$wgSessionCacheType=CACHE_DB;. If you're unsure about how it's configured, add this setting at the end of your LocalSettings.php.
• Be suresession.auto_start is not set to 1 or true, otherwise PHP sessions will overwrite MediaWiki sessions. (T159567)
• Be suresession.referer_check is set to an empty string. It marks sessions as invalid if configured incorrectly.
• If set, be sure$wgCookieDomain and$wgCookiePath are correct.
• If$wgCookieSecure is set to true, your webserver must be served with HTTPS.
• Ensure the hostnames match in MediaWiki and Apachehttpd.conf. For example, for the domainexample.com and the web server located atwww.example.com:

  # LocalSettings.php$wgServer           = '//www.example.com';$wgCanonicalServer  = 'https://www.example.com';$wgSitename         = 'Example Wiki';$wgSecureLogin      = true;$wgCookieHttpOnly   = true;$wgCookieSecure     = 'detect';

  And:

  # httpd.conf<VirtualHost *:80>   ...   ServerName example.com   ServerAlias www.example.com *.example.com   Redirect permanent / https://example.com/   ...</VirtualHost><VirtualHost *:443>   ...   SSLEngine on   ServerName example.com   ServerAlias www.example.com *.example.com   ...</VirtualHost>

• If you file a bug report:
  • Report what MediaWiki version you use and what session providers you are using (the value of$wgSessionProviders).
  • Check yourlogs for relevant records, especially theauthentication,session,cookie,objectcache channels (besides the usualexception,error,fatal). Alsocaptcha if your are looking into CAPTCHA issues, andCentralAuth if you are using that extension.
  • For certain types of cache you can get more information by setting debug mode:

    $wgHooks['SetupAfterCache'][]=function(){global$wgSessionCacheType;ObjectCache::getInstance($wgSessionCacheType)->setDebug(true);};

  • Please do not reuse old bug reports unless you are sure it's the same cause. There are lots of reports about past issues, and the while symptoms will usually look vaguely similar to yours (there are only so many ways login can fail) the cause is likely to be different.

• Debug