信頼と安全製品/仮アカウント/開発者向け
このページは仮アカウントの技術的側面の一部を説明しています。 これは利用者スクリプト、ボット、その他のツールを更新しようとする人に役立つかもしれません。
自分の拡張機能のために仮アクターを作成
皆さんがメンテナンスしている機能が IP アクターを作成している場合、仮アカウントの導入に向けて更新する必要があります。該当するのは以下の場合です:
- 実行者を含むオンウィキのログ・エントリにつながるすべてのワークフローで、当該の実行者が現状IP アドレスを名前とする利用者になり、IP アクターを作成する可能性があるもの。
- より一般的には、(1)
actorテーブルに別の行を追加し、(2) 非ログイン利用者 (匿名利用者や IP 利用者ともいう) によって実行され、IP アクターを作成する可能性があるすべてのワークフロー。
- なぜこの措置が必要?
- 仮アカウントを有効化したら、IP アドレスを名前として持ついかなるアクターも作成したくありません。
- これまでの作業の大半は、編集(特に
EditPage経由、その他action=edit、ApiEditPage,ApiVisualEditorEdit経由など)に注力してきました。 ログアウトした利用者がこれらの手段で編集した場合、その利用者用に仮アカウントを作成します。 - しかし、アクターは(ログアウトした利用者として構造化データを編集するなど)他のワークフローを介して作成される可能性があります。 これらワークフローが更新されるまで、メディアウィキは IP アドレスを名前に使う利用者を保存し続けます。
何をどうするか、詳細な指示は以下の見出しをご参照ください。
この変更関連の設計ガイドライン
- まずは、IP編集者権限と同等。最初は、仮アカウントの体験はこのような編集者が利用可能な機能に関して従来のIPの体験と同等に最小限であるべきです。仮アカウントのアーキテクチャには、より豊かで持続的な体験をログアウトしている人々に提供する余裕があるものの、この大きな転換の間にコミュニティが受ける変化をできるだけ小さくするために、これらの機会は初期ローンチの後まで先送りすべきです。
- 仮アカウントは短命なものと感じられるべき。 アカウントを持っていないときにアカウントを持っているように思われてはならず、(IP編集者に表示されるのと同様に)ログアウトを維持するのではなくアカウントを作成する動機を強調するなど教育の余地があります。
- 誰でも編集できると明確にすること。 同様に、仮アカウントを使う人に、編集を続けるためにアカウントの作成は必須ではないことも明確にすべきです。 ウィキメディア・プロジェクトの設立原則の 1 つを維持すること。
- 案内と教育を新しい体験に組み込む。
- アカウントが消えたときに人々を動揺させたり混乱させたりすべきではありません。
- IP編集と比較して仮アカウントではプライバシーが減少していると人々に認識させるべきではありません。むしろ、IPアドレスが権限を持つ利用者以外には表示されなくなったので、仮アカウント編集者はIP編集と比較してプライバシーが改善していることを強調する機会を検討してください。
コードを更新するには?
まず自分で考えてみる質問
この質問には単純でひとつの答えはありません。 仮アカウントは匿名編集者を表す新しい方法であり、ソフトウェアの一部には大きな影響を与える可能性がありますが、他の部分にはほとんど影響がありません。 解決策には多くの製品調査が必要になるかもしれませんが、技術的には単純な修正で済む場合もあります。 または、技術的な修正が複雑で、専門知識や判断を要する場合もあります。
コードに影響が出る可能性のある例と、その修正方法の考え方 (免責事項: 以下は網羅的ではありません):
- 未登録利用者は利用できない機能。 仮アカウント利用者でも利用可能にすべきか?
- 匿名利用者と登録済み利用者で異なる動作をする機能。 仮アカウントではどのように動作すべきか?
- 匿名利用者は信頼できず、登録利用者は信頼できると想定している機能。 仮アカウントをどのように扱うべきか?
- 匿名利用者と登録済み利用者で異なる UI メッセージを表示する機能。 匿名利用者には何を表示すべきか?
- 登録利用者に個人設定があると想定している機能。 仮アカウントには個人設定がないため、現在は名前付き利用者かどうかを確認する必要があります。
- 登録利用者にウォッチリストがあると想定している機能。 仮アカウントにはウォッチリストがないため、現在は名前付き利用者かどうかを確認する必要があります。
- 登録利用者に権限があると想定している機能。 ただし、仮アカウントは匿名利用者と同じ権限しか持たない (Special:ListGroupRights を参照) ため、コードもそれに合わせて更新する必要があります。
- ある機能が利用者名に含まれる IP アドレスを探す場合 (もはや見つからなくなる)。 その機能が IP アドレス (または関連情報、例: 位置情報データ) を漏らさない場合は、代わりにリクエスト データ内を
$request->getIP()を使って確認してください。 そうでない場合、その機能は廃止するか、チェックユーザー、管理者、および新設の「仮アカウント閲覧者」グループの利用者のみが使用可能にすべきです。 - 統計は匿名利用者と登録利用者で別々に集計されます。 仮アカウント利用者はどのように分類すべきですか?
- 利用者は匿名か登録済みかがフラグで示されます (例: 記録や API の結果)。 仮アカウントはどのようにフラグ付けすべきですか? これらのフラグを確認する機能は何を知りたいのでしょうか? ほとんどの API では、仮アカウントは IP 利用者とは別にフラグ付けされていることに注意してください。 (T341228)
- Some feature or part of the infrastructure assumes that the
usertable will keep growing at its current rate. This assumption won’t hold after temporary accounts are enabled: theusertable will grow more quickly. - Some feature or part of the infrastructure assumes that the ratio of registered to anonymous users accessing Wikimedia sites will stay roughly the same. This assumption won’t hold anywhere that temporary users are treated as registered users.
- A feature that relies on looking at the user’s ID to identify if the user is registered or unregistered. Temporary accounts will not have a
user_idof 0. An example of this might be instrumentation. - An A/B test is being conducted with registered users. Should the test filter out temporary users and only compare named users?
We are doing an audit of features that might be affected (T349219), and will contact you if we discover you are affected. However we may not find everything.
利用者種別の検証を更新する
PHP
最も単純な場合、利用者の種類をチェックする部分を更新するだけで済むかもしれません:
| コードがチェックしていたのは... | やりたいのは... | 今後コードがすべきは... |
|---|---|---|
$user->isRegistered()
|
仮利用者を登録済み利用者と同様に扱う | 変更の必要なし |
$user->isRegistered()
|
仮利用者を匿名利用者と同様に扱う | $user->isNamed() をチェックする
|
$user->isAnon()
|
仮利用者を登録済み利用者と同様に扱う | 変更の必要なし |
$user->isAnon()
|
仮利用者を匿名利用者と同様に扱う | !$user->isNamed() をチェックする
|
$user->isRegistered() or $user->isAnon()
|
仮利用者を登録済み利用者または匿名利用者とは異なる扱いにする | $user->isTemp() に対する別のチェックを追加する
|
UserIdentityUtils サービスには同じメソッドが用意されており、UserIdentityUtils が利用可能な場合に使用するべきですが、完全な User (または Authority) オブジェクトでは使用しないでください。
UserNameUtils サービスには isTemp というメソッドもあります。
JavaScript
同様のメソッドは JavaScript でも mediawiki.util および mediawiki.user モジュール経由で利用できます:
mw.user- for the current user onlymw.user.isAnon()- true if IPmw.user.isTemp()- true if temporary accountmw.user.isNamed()- true if regular account
mw.util- can pass any username as a parametermw.util.isIPAddress( username )- true if IPmw.util.isTemporaryUser( username )- true if temporary account
しかし、より複雑な製品上および技術上の解決策を必要とする、さらに複雑な例も確認されています。 例えば、IP アドレスが編集禁止になっている場合、匿名利用者のみをブロックするオプションがあります。 このブロックは仮アカウントにも適用されるべきでしょうか? 別のオプションが必要でしょうか? コードの更新には、コア PHP クラス、UI フォーム、サイトの設定オプション、データベース スキーマの変更が含まれる可能性があります。 同様に、他の製品にも重要な更新が必要になる場合があります。
仮アカウントに対応するために製品を再設計する必要がある場合があるため、自身の製品を慎重に確認することが重要です。
匿名、非ログイン、未登録、名無しとは? 用語集の単語
| 説明 | 提案 | Our proposal | |
|---|---|---|---|
| 文書化 | コード | ||
| IPアドレスによって識別される利用者 | IP、匿名、ログアウト、未登録 | IP利用者 | User::isAnon を User::isIP に名称変更、または完全に除去
|
| 何らかの操作を実行したときにアカウントが自動作成された利用者 | 仮、名前なし、制限 | 仮利用者 | User::isTemp を保持、または User::hasTempAccount に名称変更
|
| 完全な登録プロセスを経た利用者 | 登録済み、名前あり、正規 | 永続利用者 | User::isNamed を User::isPermanent または User::hasPermanentAccount に名称変更
|
user テーブルに行がある利用者
|
登録済み、「アカウント」を含む何か | アカウントを持つ利用者 | User::isRegistered を User::hasAccount に名称変更するか、削除して代わりに User::getID を確認
|
仮利用者を新しく作成
自身の機能が actor テーブルでIPアドレスを名前とするアクターを作成する操作の実行をログアウト利用者に認めている場合、代わりにログアウト利用者が最初に操作を実行したときに仮アカウントを作成することが必要になります。
IPアドレスを名前とするアクターを作成しようと試みると、仮アカウントが有効化されている場合はエラーを投げるようになります。
やること:
- File a subtask of T349129 (example subtask: T349130)
- 権限設定により全員 (グループ
*)に対して操作の実行を認める場合、これらのいずれかを行うことのみが必要です。 Keep this configuration. ログアウトした利用者がその操作を実行できない場合、仮アカウントは自動作成されません。 - あなたの機能が扱う操作/権限が
editでない場合、$wgAutoCreateTempUser['actions']の仮アカウントを作成する操作の一覧に追加してください。 (The list containseditby default.) TempUserCreatorを使って仮利用者を作成します。 T359405 に従い、a) 操作が成功しそうになってから(例:権限チェックやその他エラー発生の可能性があるチェックの後で)、ただし b) 編集試行の失敗を参照するためログ・エントリを生成する可能性のあるコードの前(例: AbuseFilter の段階)にこれを行います。 (仮アカウント作成後は、グローバル コンテキストの利用者とは異なることに注意してください。)- To see an example, look at
EditPage::createTempUser.EditPageには、仮アカウント作成前に仮アカウント名を表示したプレビューを出す必要があるという追加の複雑さがあることに注意してください。 これは通常あまり必要とされない要件ですが、必要であればあなたの機能で再実装することもできます。 - 操作 API ハンドラー(
ApiBaseを拡張するものすべて)でApiCreateTempUserTraitを使うとreturntoとreturntoquery、returntoanchorパラメータに正しい値を指定し、そのApiCreateTempUserTraitが統一認証 CentralAuth(またはonTempUserCreatedRedirectフックを処理するいずれかの拡張機能)を介して、ログイン用リダイレクト URL を作成します。 - その他の (操作 API 以外の) コンテキストでは、リダイレクト URL を作成してから
onTempUserCreatedRedirectフックを実行します。これにより中央管理ログイン用に URL が変更されます。 例はEditPage::doPostEditRedirectを参照してください。 - 操作完了後に仮アカウントとは何かを説明するポップアップを表示したい場合は、
mediawiki.tempUserCreatedモジュールを使用してください。
onTempUserCreatedRedirect フックの試験
ローカルに完全な CentralAuth 環境がなくても、このフックを正しく使用しているか確認するには、LocalSettings.php 内で以下のスニペットを使用できます:
$wgHooks['TempUserCreatedRedirect'][] = function (
\MediaWiki\Session\Session $session,
\MediaWiki\User\UserIdentity $user,
string $returnTo,
string $returnToQuery,
string $returnToAnchor,
&$redirectUrl
) {
if ( $returnTo === '' ) {
$returnTo = \MediaWiki\Title\Title::newMainPage()->getFullText();
}
if ( $returnToQuery === '' ) {
$returnToQuery = 'redirected-by-hook=yes';
} else {
$returnToQuery = "redirected-by-hook=yes&$returnToQuery";
}
$redirectUrl = \MediaWiki\Title\Title::newFromTextThrow( $returnTo )
->getFullURL( $returnToQuery ) . $returnToAnchor;
};
これは、指定したタイトル、クエリ、およびアンカーにリダイレクト URL を設定します (中央管理ログインを経由せず)、さらにクエリに redirected-by-hook=yes を追加して、フックが使用されたことを確認できるようにします。
不正利用フィルターを更新
条件でIPを使うAbuseFilterで使用されているフィルターは仮アカウントで機能するように更新が必要かもしれません。
中でも user_name 変数は IP を返さなくなると予想され、そのアクセス経路に依存する条件は破れてしまうはずです。
以下の移行手順が想定されていますが、変更される可能性があります:
ip_in_rangeまたはip_in_rangesを使用する条件は機能しなくなります。なぜなら、通過するuser_nameには匿名利用者の IP が含まれなくなるからです。 代わりに、新たに提案された変数user_unnamed_ipを使用すべきです。 Work on this is tracked via phab:T357772.- IP にアクセスするために
user_nameを使用する条件は、代わりに提案されたuser_unnamed_ip変数を使用する必要があります。 user_ageやuser_groupsを介して暗黙的に IP / 匿名利用者を確認する条件は、正常に動作しない場合があります。 代わりに、新しいuser_type変数を使用してください。この変数は以下のいずれかを返すことができます:named,temp,ip,external,unknown。 フィルターの動作内容によっては、tempとipの両方の値でフィルターをかける必要があるかもしれません。
user_unnamed_ip は匿名利用者と仮アカウントの両方に対応しているため、user_name を使用しているフィルターは user_unnamed_ip に更新することで、フィルターの移行を容易にできます。これは、仮アカウントがそのウィキで導入される前に各ウィキで実施しておくべきです。
不正利用フィルターの許可を更新
IP を個人識別情報 (PII) としてサポートするために、AbuseFilter では保護変数という概念が導入されました。保護変数とは、機密情報を含み、そのアクセスが制限されている変数です。
user_unnamed_ip is a protected variable.
保護変数を使用するフィルター自体も保護されていると見なされ、編集および閲覧のアクセスも同様に制限されます。
The following rights have been added:
| Right | Description |
|---|---|
abusefilter-access-protected-vars |
保護された変数を使用するフィルターを表示および作成 |
abusefilter-protected-vars-log |
保護された変数へのアクセスに関連する記録を表示 |
保守担当者は、保護変数に関連するフィルターや記録を作成/閲覧するために abusefilter-access-protected-vars が必要になります。
Additionally to access the IPs of temporary accounts, the user will need to have access to an IP reveal right (either checkuser-temporary-account or checkuser-temporary-account-no-preference).
詳細は Extension:AbuseFilter/規則の書式 を参照してください。
Retrieving the IP of temporary accounts
For those scripts and bots that relied on the IP address of anonymous accounts (e.g., scripts that help find and block open proxies), an additional step will be required: the script will need to use the REST API to retrieve the latest IP address associated with each temporary account.
You can use /checkuser/v0/temporaryaccount/{name} for a single temporary account, or /checkuser/v0/batch-temporaryaccount for multiple temporary accounts.
Additional information is available by accessing the REST API Sandbox.
説明文書の更新
本件に関連し、コミュニティ対応の変更を完了した段階で、恐れ入りますが更新ページにその情報を投稿してもらえないでしょうか。
開発者のよくある質問
技術面で言うと変更点は?
仮アカウントは user テーブルにあり、事実上は正規アカウントですが、いくつかの違いがあります:
- アカウントが作成されるとき、利用者のブラウザにcookieが設定されます。このcookieは利用者のIPアドレスが変わっても、この利用者によって実行されたすべての後続の編集を帰属させるために利用されます。原則的に、IPに直接的に帰属させる編集はもうありません。仮アカウントはcookieが存続する限り存続します。cookieは最初の編集から1年後に期限切れになるよう設定されます。
- 自動的に生成された利用者名がこの利用者に割り当てられ、パスワードはありません。したがって、この利用者アカウントにログインすることは不可能です。アカウントが作成されたときに設定された期限切れしていないcookieを持っていることだけが、この利用者としてログインする唯一の方法です。
- コードでは:
User::isRegistered()は仮アカウントを含む、すべての登録済み利用者に対して true を返します。User::isAnon()はこのような仮アカウントに対して false を返します。User::isTemp()は専ら仮アカウントに対してのみ true を返します。User::isNamed()は専ら仮アカウントではない登録済みアカウントに対してのみ true を返します。
- 仮利用者名はチルダで始まり、普遍的な書式を取ります : ~12345(書式は設定
$wgAutoCreateTempUser['genPattern']で定義される)。 - A temporary user will be represented by a row in the
usertable. A row can only be determined as representing a temporary (as opposed to registered) user via the name stored in user.user_name. A temporary user name will match the config$wgAutoCreateTempUser['matchPattern'].
仮アカウントが有効になっているかどうかを自身のコードでチェックする方法は?
TempUserConfig インターフェイスには関連するメソッドが 2 つあります。
isEnabled()は、仮アカウントの自動作成が現在有効であることを示します
isKnown()indicates that temporary accounts are a known concept on the wiki. It does not mean that auto creation of temporary accounts is currently active. It does mean that temporary accounts may exist on the wiki.
私のツールでも仮アカウントを正規アカウントと同等に扱うべきか?
機能によって異なります。仮アカウントでポイントや履歴や個人設定などを生じることを利用者に認める場合、アカウントの有効期限が切れると当該の利用者はそれらをすべてを失う点にご留意ください。これは、仮アカウントの利用者にとって好ましい結果ではないかもしれません。その他の点は、正規アカウントと同様に扱うのが安全策かもしれませんが、その製品を最もよく理解しているあなたご自身のご判断にお任せします。
IP 利用者向けには存在しなかった仮アカウント向けの追加機能を提供することにした場合は、ぜひお知らせください。私たちは、以前の未登録利用者に比べて仮アカウントにどのような追加機能が提供されるかを追跡しています。
利用者そのものが匿名利用者に類似するなら、なぜ仮アカウントを名前付き利用者アカウントと非常によく似た方法で展開するのか?
- CentralAuth integration was a product requirement. After saving a revision, the user is logged in on all wikis. Implementing this without creating a user row would have been very challenging.
- Creating a user row allows us to share session management infrastructure with logged-in users. The long-lived cookie which keeps the temporary user logged in is identical to the “remember me” feature for regular user accounts.
- 仮アカウントは、名前付きアカウントと同様に、特定の利用者の行動を表すことを目的としています。一方、匿名 (IP アドレス) 利用者は複数の異なる利用者を表すことがあり、1 人の利用者が複数の IP アドレス利用者として同時に行動することが想定されます。
User::isRegistered は仮アカウントに対して false ではなく true を返すのか? 正しい扱いは匿名利用者と同等では?
仮アカウントは内部的には名前ありアカウントのように振る舞い、類似の現実世界の実体(つまり人)を表します。この概念 - およびソフトウェア - は User::isRegistered が false を返した場合混乱します。
Many features need to treat temporary accounts the same as named users: for example, temporary users can request tokens and use these as identifiers when editing via the API, e.g. in order to build an edit history via mobile apps.
Features can be updated on a case-by-case basis to treat temporary users like anonymous users or named users (or in a different way to either).
新規作成したアカウントを我々のデータベースは処理し切れるのか?
We can't be sure exactly how many extra new accounts will be made, but if it's in the order of the low double-digit millions per year (as suggested by phab:T327365#8558972), then the corresponding growth of the user and actor tables is acceptable. The size increase of the user_properties table would have been a concern, but temporary accounts can't save preferences, so won't add rows to this table.
データベースには IP アドレスの代わりに何を保存する?
actor テーブルは、actor_name 列にアクター名として IP アドレスを格納します。
仮アカウントが有効な場合、新しい利用者は IP アドレスを名前として持たないため、代わりに仮アカウント名が actor_name 列に格納されます。
ip_changes テーブルも IP アドレスを格納しますが、仮アカウントによる編集には ip_changes に行は作成されません。
データベースのどこに IP アドレスを保存する?
IP addresses for temporary users will be stored the same way for temporary users and users with a full account. They will be stored in the CheckUser tables for a limited time, then they will be purged from the table.
従来の IP アドレスは秘匿されますか? IP アドレスが既にデータベースに保存されているの場合、除去されますか? IP アドレスを名前とする User オブジェクトをインスタンス化することは可能ですか?
仮アカウントが有効化された後も、仮アカウントの有効化以前に可視化されていたIP アドレスは、可視化されたままです。
それらのIPアドレスはデータベーステーブルに存在したままです。
IP アドレスを名前とする User オブジェクトをインスタンス化することは可能なままです。
Varnish キャッシュを迂回しようとするトラフィックが増える原因になりませんか?
最近の IP 編集者はすでに Varnish cache を迂回しているため、この件に影響はないはずです。非ログイン読者も Varnish cache で検出します。
仮利用者の mw.config.get('wgUserName') は何ですか?
仮利用者の名前を返します(一方 IP 利用者に対しては null を返します)。これは仮利用者も登録利用者と同じように実装されていて、名前へのアクセスが必要になる場合があるためです。
JavaScriptで mediawiki.util および mediawiki.user モジュールを使って、特定の利用者が仮利用者かどうかチェックできます:
mw.util.isTemporaryUsermw.user.isTempmw.user.isNamed
仮利用者の mw.config.get('wgUserGroups') は何ですか?
これは [ "*", "temp" ] を返します。
仮利用者はグループに割り当てられたり、自動昇格または自動承認されたりしますか?
いいえ。これらは仮アカウントにはできません。
私はツールまたはサードパーティMediaWiki拡張機能の開発者です。自分のニーズを財団に伝える方法は?
作業に対するタスクは、 phab:T326816 のサブタスクとして追加します。
仮アカウントを有効にしたらPHPUnit テストで私の拡張機能が壊れた
テストの更新方法は、例えばパッチの例として phab:T365645 および phab:T365669 を参照してください。
このページに答えがない質問がある
関連項目:
- 当プロジェクトの基本情報、法律情報、役務者との質疑応答などは The general FAQ を参照してください。
- T326816 および T300263 には、技術面の詳細を示してあります。
当チームとの連絡はトークページでも受け付けています。