CentralAuth

提供:ct777-wiki
ナビゲーションに移動 検索に移動

名前を知らなくてもWikimedia、Miraheze、そしてEnpediaのアカウントシステムに使われていると言えばわかるこの拡張機能CentralAuth。複数サイト間でアカウントを共通化し、ユーザー名重複を防止、グローバルロックやブロック、グローバル権限の有効化など様々なことを実現する偉大な発明だが、導入は他と比べて極めて難しい。

普通の拡張機能は1つのサイトにしか作用しないが、CentralAuthは異なるデータベース間でアカウントを統合し、グローバルグループ、Wiki集合...という新たな概念を導入するため、手順もリスクもある。

なおかつ、お約束のごとく公式が解説に乏しい。そして古い。

できること[編集]

(書きかけ)

先行例[編集]

  • Enpedia - 2ndから3rdに移転するためだけに導入。2ndが事実上閉鎖された現在でもCentralAuthが稼働している。苦戦せずさらっと導入出来たあたり流石WikimediaのStewardを務められた方である。
  • Wikimedia - 本家なので、当然運用中。
  • Miraheze - 余裕で運用。毎日のようにwikiが作られては消える複雑な環境でよくやっていると思う。
  • ちなみに、myhtやlv9時代のウソペディアはメインサイト・コモンズ・ウソメタ...など複数サイトで構成されており、またスパム被害で度々myht内で移転新設していたため、スムーズな移行のためにも導入を模索していた形跡があるが、技術的な壁を乗り越えられず断念している[1]
  • mw:Extension_talk:CentralAuth - 10年以上蓄積した叫び。

失敗(~2020年)[編集]

自分はMW熱に波があるため、数年に分けて短期集中でこれまで4回ほど挑戦してきた。環境は(資金的な問題で)3回がmyhtで全て失敗し、新調したPCローカル内でやった4回目で初めて成功した。

通常の拡張機能の導入は、ファイルをextensions内に設置し、LocalSettings.php内に追記し、必要な場合はDBをアップデートするだけ。

一方CentralAuthには上記以外にSQLで記録用データベースの作成、グローバルグループに所属させるためのスクリプト実行、$wgConfで他のサイトを定義(クソややこしい)するetc...と長い長い。

さらに、構成するwikiそれぞれ1つずつデータベースを必要としており、単一のデータベースを複数のwikiが共用していると使えないと厳しい。

結論から書くとmyhtではSSHができないためだった。MW本体はSSHがなくても稼働できる[2]が、こんな発展的な拡張機能は甘くないわけである。

手順[編集]

以下は成功したWindows10のPCローカル環境下での手順。おおむね他の環境でも同じはず。

  • 導入時MediaWikiは1.36.0。xamppを利用して環境を構築。PHPは8.0.9、MariaDBは10.4.20。2022年Windows11となった状態で1.37.1へのアップデートにも成功。
0. xamppのhtdocs/内にw1及びw2の2サイトを設置。データベースをmain_wikisub_wikiとする[3]。ShortURLにより前者にはhttp://localhost/wiki1/後者にはhttp://localhost/wiki2/でアクセスできるものとする。
  1. 公式から拡張機能を入手する。wgetでも、gitでも、普通にダウンロードしても何でもよい。
    • 例)
      wget extdist.wmflabs.org/dist/extensions/<バージョン>.tar.gz
  2. 構成するwikiの各extensions/内に展開。
    • tar -xzf CentralAuth-<バージョン>.tar.gz
  3. CentralAuth用のデータベースを作る。
    1. centralauthというデータベースを作り、適切なユーザーに適切な権限を与える。
    2. このままではまだからっぽなので、CentralAuthディレクトリ内のcentral-auth.sqlを実行する。一回だけでOK.
    • ひたすら文字を打つよりも、このあたりの作業はphpmyadmin内で実行したほうが良い。直感的に操作でき、ミスも減るはず。
    • 他のデータベース内に作っても良いが、経験上うまくいかなかった。
    • データベース名が決まっているmyhtはこの辺で限界。
  4. それぞれのLocalSettings.phpに追記(wfLoadExtension( 'CentralAuth' );)する。詳細設定は後回しでよい。
  1. そもそもスパム対策すらままならなかった中で出来るはずがない。
  2. 例えばDBの更新時、推奨はupdate.phpの実行だが、ウェブアップデーターで代用できる。メンテナンススクリプトはSSHでないと使えないが、動かさなくても基本支障ない。
  3. データベースの名前は何でもいいが、何かしらの接尾辞で統一した方が良いらしい。実際、後の設定でそれを実感した。