API:Login/ja

MediaWikiのWebサービスAPIを使う場合、おそらくはアプリケーション・クライアントからログインする必要が出てくるでしょう. このためには、ログインクエリーを送信する、クッキーを構築する、MediaWiki側から送られてきた確認トークンを送り返すなどの手順が必要となります.

ログインの必要性
以下のような場合には、MediaWikiにログインしてAPIを使う必要があります.


 * 特定の権限を持った利用者にしかできないことをしようとする場合
 * 膨大なリクエストを発行するため、リクエストの制限を上げたアカウントでないと実行が現実的でない場合

匿名での編集が可能なウィキの場合、ログインせずにAPIを使うこともできますが、できるだけログインして実行すべきです. プライベートウィキでは、どんなAPIを使うにもログインが必要です.

JavaScriptを使って、ブラウザ内で動かすようなクライアントを書く場合、ブラウザでログインしておけばAPIを使う際に改めてログインしなくても、ログインしたアカウントとしてAPIを使えます.

アプリケーションごとのアカウント
アプリケーションを通常のアカウントでログインさせるのでなく、アプリケーションで使うため専用のアカウントを用意した方がいい場合があります. 特に、 には、専用アカウントが特に便利です.
 * 自動で編集を行うなど、大量の操作を行う場合
 * 巨大な、あるいはパフォーマンスが重要になるクエリを仕掛ける場合

アカウントを別に用意すれば、アプリケーション経由の編集を識別可能になりますし、そのアプリケーション単位の権限設定（「bot」フラグなど）も可能になります. ウィキによっては、自動編集を行う場合のルールを決めているところや、「bot」フラグの着脱ルールが決まっていることもあります.

ログイン時には、サーバ側から認証に必要なトークンの組が渡されます. api.phpを呼ぶ場合、そのトークンの組をCookieとしてリクエストごとに送信する必要があります. Cookieはおよそ1ヶ月ほど有効ですので、セッションのたびにログインするような実装ではなく、ログイントークンを保存しておいて、自身がログアウト状態かをチェックすることでログインの必要性を判断するようにシステムを組むほうがよいです.

ログイン方法
API経由でログインするには、まずログインクエリーを送信して、クッキーをセットする必要があります（フレームワーク側でクッキーを処理してくれるものも多いです）. MediaWiki 1.15.3以降では、送られてきたトークンを送り返すことでログインを確認する、というステップが増えています.

ログインリクエストの構造
先ほどのリクエストで、ヘッダにもクッキーが返されています（ ）. フレームワークで自動的に処理されない場合、続くリクエストにこのクッキーを含める必要があります. パラメーターはMediaWiki 1.17以降で追加されています. なお、リクエストの結果がHTMLとして返ってきてしまうばあい、引数に （あるいは他の適当なもの）を指定する必要があります.

認証にExtension:LDAP Authenticationのような拡張機能を使う場合、認証のためのドメインを与える引数として を使うことになる場合もあります.

確認トークン
先ほどのクエリで ではなく が返ってきたら、このステップは必要ありません（確認ステップは、MediaWiki 1.15.3以降で必要となります）. MediaWiki 1.15.4では、ApiLogin.phpの1段階目にバグがあり、必要なトークンが返ってこないため確認ステップを完了させられなくなっています. とりあえず対処するには、ApiLogin.phpファイルをMediaWiki 1.15.5のものに置き換える、という方法があります（なお、MediaWiki1.16以降のApiLogin.phpでは、互換性がないため動作しません）.

クッキーの作成
が成功すると、クッキーが生成されます. cURLのcookiejarのように、フレームワーク側で処理してくれる場合も多いですが、そうでない場合はプログラム側で管理が必要となります.

もちろん、 ヘッダをパースしてクッキーを組み立てても構いませんが、CentralAuthのないウィキでは、レスポンスボディからクッキーを作ることができます.


 * 具体例をあげてみると、上の例では2度目のリクエストの際に以下のようなクッキーをセットすることとなります.
 * enwiki_session =  (レスポンスの 値)
 * そして、ログイン後には以下のようなクッキーが必要となります.
 * enwikiUserName =  ( 値)
 * enwikiUserID =  ( 値)
 * enwikiToken =  ( 値)


 * なお、 の部分はウィキごとに異なってきます（ の値を使います）.

ウィキメディア・プロジェクトのようにCentralAuthが有効な場合、上のような方法や、クッキーをそのまま受け入れるだけの方法では、1つのウィキにしかログインできません. SULを適用したい場合は、次の節にあるように、 を自前でパースして、必要なクッキーを生成する必要があります.

CentralAuth SUL ログイン

 * 1) ふつうにログインします.
 * 2) レスポンスヘッダーの として、通常ログイン用のクッキー以外にSUL用のクッキーも返ってきます（通常、単独のウィキに必要なクッキー3つとSUL用のクッキーが3つ、合わせて6つの値になっています. 例えばウィキメディア・コモンズでは、,  のようになっており、太字のものがSUL用の値です）.
 * 3) あとはクッキーの中から、 で始まるものを抜き出して、他のドメインにも同じクッキーを適用させるだけです.

例えば、ウィキメディア・プロジェクトでは、以下のドメインに対して同じクッキーをセットします.
 * 1) * .wikipedia.org
 * 2) * .meta.wikimedia.org
 * 3) * .wiktionary.org
 * 4) * .wikibooks.org
 * 5) * .wikiquote.org
 * 6) * .wikisource.org
 * 7) * .commons.wikimedia.org
 * 8) * .wikinews.org
 * 9) * .wikiversity.org
 * 10) * .mediawiki.org
 * 11) * .wikidata.org
 * 12) * .species.wikimedia.org
 * 13) * .incubator.wikimedia.org
 * 14) * .wikivoyage.org

エラー
エラーが起きると、 に起きたエラーの種類が返ります. 返り値は以下のようになっています.
 * lgnameをセットせず、あるいは空でリクエストした場合
 * 利用者名として不適当な値を指定した場合
 * 指定した利用者が存在しなかった場合
 * lgpasswordをセットせず、あるいは空でリクエストした場合
 * パスワードが正しくなかった場合
 * MediaWiki自身でなく、拡張機能での認証に失敗した場合
 * アカウントを自動生成しようとしたものの、IPアドレスにアカウント作成のブロックがかかっていた場合
 * 短時間に多数のログインリクエストを行った場合. も参照のこと.
 * 利用者がブロックされていた場合
 * ログインリクエストをPOSTでなく、GETで行おうとした場合
 * ログイントークンとクッキーの両方が揃っていなかった場合. これは正常なログインの過程でも一度は発生します.
 * MediaWiki自身でなく、拡張機能での認証に失敗した場合
 * アカウントを自動生成しようとしたものの、IPアドレスにアカウント作成のブロックがかかっていた場合
 * 短時間に多数のログインリクエストを行った場合. も参照のこと.
 * 利用者がブロックされていた場合
 * ログインリクエストをPOSTでなく、GETで行おうとした場合
 * ログイントークンとクッキーの両方が揃っていなかった場合. これは正常なログインの過程でも一度は発生します.
 * 利用者がブロックされていた場合
 * ログインリクエストをPOSTでなく、GETで行おうとした場合
 * ログイントークンとクッキーの両方が揃っていなかった場合. これは正常なログインの過程でも一度は発生します.
 * ログイントークンとクッキーの両方が揃っていなかった場合. これは正常なログインの過程でも一度は発生します.
 * ログイントークンとクッキーの両方が揃っていなかった場合. これは正常なログインの過程でも一度は発生します.

速度制限
セキュリティ上の理由により、API経由のログインには速度制限があります. 標準では、5分間に5回までログインリクエストを行えますが、ウィキごとに設定変更もできます. 速度制限に引っかかった場合、 として（正しい入力でも）ログインは失敗し、制限解除までの時間が へと返されます.

例

 * PHPによるログインコード (Snoopyを使用)
 * PHPによるログインコード（cURLを使用） - Snoopyを使わない例
 * JavaScript+jQueryによるログインコード