Manual:デバッグの方法/ログインの問題点
ログインやセッションの問題 (ログインできない、すぐにログアウトしてしまう、ランダムにログアウトしてしまう、「セッション データの喪失」エラーで編集できないなど) は、多種多様な原因があるため、デバッグが困難です。
エラーを調査・報告する際の注意点を紹介します。
利用者向け
- 「ログインセッションに問題があるようです」というエラーでログインできない場合は、多くは一度当該サイトのCookieを消去すると解決します。
- バグを報告する際は、使用しているブラウザ(およびそのバージョン)、シークレットモードを使用しているかどうか、ブラウザのプライバシー/セキュリティ設定を既定のものから変更しているか(たとえば「サードパーティーのCookieをブロックする」に設定している、など)といった情報を必ず含めてください。
- 可能であれば、問題が発生した日時を正確に記載してください。システムログと関連付けができるようになります。
- バグの報告を提出するにあたって、通常は報告者が詳細に調べ上げる必要はありません。もし調べてみるのであれば、以下が参考になるでしょう。
- ウィキ ドメインの Cookie を消去しても持続しますか? シークレット・モードでログインしても改善しませんか? 別の種類のブラウザでログインしても改善しませんか?
- 広告ブロックやブラウザのプライバシー設定を使用している場合、何かブロックされていませんか? オフにしても改善しませんか?
- 複数の利用者アカウントで起きますか? それとも 1 つの利用者アカウントのみですか?
- Remember Me認証(「ログインしたままにする」のチェックに関わる認証)に何か違いはありませんか? (施行前にCookieを消去してください)
- もしWikimediaのウィキで問題が起きた場合は、ほかのウィキへのログインを試してください。このとき、セカンドレベルドメインが違うサイトで試すのが望ましいです。たとえば、「xy.wikipedia.org」で問題が起きた時は、「.org」の上が「wikipedia」ではないサイト、「xy.wiktionary.org」などで試してみるべきでしょう。
- 上記の情報でも問題を診断するには十分ではないと判断されると、より詳細なデバッグデータを取得するように求められることがよくあります。 そのため、関連するHTTPリクエストとレスポンスを記録する必要があります。具体的には、ログインページへの訪問、ログインフォームへの投稿、リダイレクトの結果などが対象です。そのウィキが単一のサインオンを使用している場合、
Special:CentralLogin
とSpecial:CentralAutoLogin
へのすべてのリクエストも同様に記録の対象になります。 これは、ウェブブラウザに付属している「デベロッパーツール」を開き、「ネットワーク」タブを使用すると確認できます。(詳細: https://developer.mozilla.org/docs/Tools/Web_Console - Firefox、http://msdn.microsoft.com/en-us/library/ie/dn255006 - Internet Explorer、https://developer.chrome.com/devtools Chrome・Chromium、https://developer.apple.com/safari/tools/ - 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 to use 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.
For developers
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" )
, using shell.php ).- If you are debugging an API-based login, the cookie should instead be set by the response to
meta=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 use owner-only consumers and not use login at all.)
- If you are debugging an API-based login, the cookie should instead be set by the response to
- 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 like XDebug, for session/cookie problems the interesting parts tend to be the
provideSessionInfo()
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 with SessionManager 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 be
centralauth_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 )
(using shell.php ). The token corresponds toglobaluser.gu_auth_token
in CentralAuth's shared database. - After a successful login, there should be a chain of redirects to
Special: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. the
centralauth_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.
- The "keep logged in" flag (ie. the
- 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 the
CentralAuthAnon
localStorage flag; you might need to clear that when testing.
- When central autologin fails, further attempts are prevented by setting the
- 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 an overview of CentralAuth authentication features available.
For site administrators
- 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 sure session.auto_start is not set to 1 or true, otherwise PHP sessions will overwrite MediaWiki sessions. (タスク T159567)
- Be sure session.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 Apache
httpd.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 your logs for relevant records, especially the
authentication
,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.
- Report what MediaWiki version you use and what session providers you are using (the value of