投稿者: blogger323

プラグインの機能拡張の時に WordPress のユーザー名関連について調べたのでまとめておきます。

ユーザー名に関する以下の項目が WP_USERS テーブルに入っています。

user_login

ログイン時に使う名前

display_name

表示用の名前

user_nicename

著者別の URL 用 (例: https://hetarena.com/archives/author/blogger323) に使われる名前

重要なのがログイン画面で入力する user_login です。 サイトへのアタックに使われると嫌なのでこれは知られたくないですね。 そこで表示用に display_name (管理画面上は「ブログ用の表示名」) というものがあって、これを設定しておくと投稿の表示などにはこちらが使われます。

ただ、ちょっと曲者なのが、user_nicename です。 これは user_login を元に自動的に設定され、管理画面から変えることができません。 そして、リダイレクトのテクニックを使うと訪問者にわかってしまいます。

どういうことかというとサイトの設定によっては以下の形式の URL にアクセスすると user_nicename を使った著者別 URL にリダイレクトされるのです。

https://hetarena.com/?author=1

このサイトでは author=1 だと URL には admin が表示されます。 admin と表示されるのは嫌だと思っても管理用 GUI からこれを変えることができません。 この動作があるので「ブログ用の表示名」を変えただけでは不十分であり、皆さんログイン名情報を隠すのに苦労しているようです。

そんな悩みをお持ちの方にちょっとしたテクニックをお伝えしておきます。 私の場合は逆にユーザー作成後に user_login を SQL 文で変えてしまっています。

UPDATE wp_users
SET user_login = 'himitsu'
WHERE id = 1;

ユーザー作成時のアカウント名はそのまま表示用として display_name と user_nicename に残しておけば良いわけです。 SQL 文でやらねばならないところがネックかも知れませんが…。

ちなみに user_nicename のデフォルト値ですが、WordPress Core の user.php 内 wp_insert_user() で以下のようにセットされてます。

$user_nicename = sanitize_title( $user_login );

それと「ニックネーム」は WP_USERS テーブルではなくて WP_USERMETA の方に保管されます。

なお、そもそもの話としては複雑なパスワードを使うというのが一番重要であることを最後に強調しておきたいと思います。

このブログのように弱小サイトでもコメントスパムが来ます。 最盛期は 1か月に 6万7千件という記録があります。 最近は減ってきたものの、それでも管理画面にログインして「200件のコメントがスパムとして捕えられています」というようなメッセージを見るのは気分がいいものではありません。 今回、原因調査と対策をしたことでスパムキューに入るコメントの数そのものを減らすことができたので、経緯をまとめておきたいと思います。

スパムキューに入るコメントの数を減らしたい

使っている人は誰でも知っていると思いますが、WordPress には標準で Akismet というスパム対策用のプラグインがついてきます。 個人用には無償で利用でき、これはこれで有難いプラグインなのですが、日本語についてはたまに誤検知が発生するようです。 少なくとも私は正規のコメントをスパムキューに入れられた経験が複数回あります。

そういうことがあると、どうしてもスパムキューのチェックをしたくなってしまいます。 スパムと正規コメントがそれこそ 10,000 : 1 ぐらいの比で入っているようなキューをチェックするのは至難の業です。 やはり、根本的な対策を行ってスパムキューに入るコメントの数を減らしたい。

そこで私は CAPTCHA プラグインを導入してみました。

SI CAPCHA を導入したのにスパムが減らない？

私が導入したのは SI CAPTCHA プラグインです。 レビュー評価も高く、最近もメンテナンスされている様子なのでこれを選びました。

しかし、何故か導入後も思ったようにスパムキューに入るコメントの数が減らなかったのです。 そこで、この原因を調べてみました。

人間じゃないな

まずは httpd のログを確認します。 スパムコメントが投稿される際のログはたった 4行でした。

192.168.138.148 - - [27/Sep/2014:10:28:03 +0900] "GET /archives/503 HTTP/1.0" 200 60116
192.168.138.148 - - [27/Sep/2014:10:28:05 +0900] "GET /wp-content/plugins/si-captcha-for-wordpress/captcha/securimage_show.php?si_form_id=com&prefix=TdkHIF8aBTtW9BWL HTTP/1.0" 200 6099
192.168.138.148 - - [27/Sep/2014:10:28:05 +0900] "POST /wp-comments-post.php HTTP/1.0" 302 -
192.168.138.148 - - [27/Sep/2014:10:28:09 +0900] "GET /archives/503 HTTP/1.0" 200 60260

通常の Web ブラウザを使った閲覧ならば、1行目のページ全体の html がダウンロードされた後に関連する画像や JavaScript 等がダウンロードされるのですが、それは行われていません。 CAPTCHA の画像 (2行目) をダウンロード後、コメントを POST (3行目) し、再度そのページを取得 (4行目) しているだけです。

注目すべきは 2行目と 3行目の間の経過時間、すなわち CAPTCHA 画像をダウンロードしてからコメントを投稿するまでの時間です。 これをみると 1秒も経たずに行われています。

以前、この世界には安価な人力を使って CAPTCHA を突破するような仕組みが存在するという話をどこかで見かけたのですが、このログを見る限り人間が処理しているわけではないようです。 私はこの時点は 2つの可能性を考えていました。 一つはプラグインが何か脆弱性を持っていてそこを突かれている可能性、もう一つは CAPCHA 画像を機械的に認識処理している可能性です。

作者の方には申し訳ないのですが、ぼんやりと脆弱性の可能性の方が高いように考えていました。

SI CAPTCHA の仕組み

SI CAPTCHA の仕組みを簡単に説明しておきます。

ブログのページが表示されたとき、4文字の CAPTCHA 文字列 (captcha_code) がランダムに生成され、その内容は cache ディレクトリ内の一時ファイルに保存されます。 保存されたファイル名にはランダムの文字列 (si_code_com) が付与されます。 先のログの「TdkHIF8aBTtW9BWL」の部分がこの si_code_com に相当します。

コメント投稿時に POST された captcha_code と si_code_com から一時ファイルの内容と合っているかを確認し、合っていなければエラーとする仕組みです。 上の図はこれらの処理をイメージ化したものです。 この例では si_code_com = TdkHIF8aBTtW9BWL、captcha_code = 9YgA です。

画像認識処理されてるよ！

SI CAPTCHA のソースコードを読んでこれらを把握したのですが、コードを読むだけでは特に問題となりそうな箇所は見つけることができませんでした。 そこで、投稿されている内容をログに記録することにしました。 具体的には si-captcha.php 内にある関数 si_captcha_comment_post() で $_POST の値を確認するようにし、プログラムが生成時に使用している captcha_code や si_code_com と比べてみました。

すると驚いたことにスパマーは正しい captcha_code と si_code_com を送ってきていたのです。 一応付け加えておくと出鱈目な captcha_code を付けて POST してくるケースもあったのですが、それらはきちんと弾かれていました。

captcha_code と si_code_com が正しいとなるとどうやら画像認識処理をしているようです。 作者さん、疑ってごめんなさい！

キューに入る前にシャットアウト！

さて、画像認識処理が機械的に行われているとなるとどうすればよいでしょうか。 高度な画像認識処理が行われていて、認識率が結構高いとなるとやっかいです。 プラグインを変えなければならないかも知れません。

それは面倒だなあと思いつつ、まずはできるところを試してみようと思いました。 何を行ったかというと SI CAPTCHA のコードをいじって文字数と画像サイズを変えたのです。

すると、スパマーが投稿する際の captcha_code に変化が見られました。

["captcha_code"]=> string(14) "!UNKNOWN_TYPE!"

やったね！！

これだけで Unknown type とか言っちゃう程度の処理エンジンであればこの対策だけで十分な気がしてきました。 恐らく画像認識処理は SI CAPTCHA の文字数と画像サイズに最適化されていたのでしょう。

これでキューに入る前に弾かれるようになりました。

変更箇所

修正の仕方が広まってスパマー側に対策されるのが嫌なので、私がどのように変えたかはあえて記しません。 興味があれば、実際のコメント欄をご覧ください。(丸わかりですね)

ここでは変更箇所だけお伝えしておきます。 それだけじゃコードを修正できないという方は、是非 SI CAPTCHA プラグインのサポートページで文字数や画像サイズが可変となるよう要望を出してみてください。

• si-captcha.php の関数 si_captcha_captcha_html() 内の以下部分の width を変更

    // url for no session captcha image
    $securimage_show_url = $si_captcha_url .'/securimage_show.php?';
    $securimage_size = 'width="175" height="60"';
    if($si_captcha_opt['si_captcha_captcha_small'] == 'true' || $label == 'si_image_side_login' ) {
      $securimage_show_url .= 'si_sm_captcha=1&';
      $securimage_size = 'width="132" height="45"';
    }
  

  これらは管理画面の CSS で変えられるかも知れません。

• secureimage_show.php の $char_length と $img->image_width の値

宣伝！

話が全然違いますが、私もプラグイン作者なのです。 以下のプラグインも是非使ってみてください！

• Thin Out Revisions
• Standard Widget Extentions

9月中旬に PhpStorm 8 がリリースされたので、ちょっと間が空きましたがバージョンアップして触ってみました。 このバージョンから WordPress に関するサポート機能が追加されています。

WordPress 開発環境のサポート

PhpStorm 8 の WordPress 関連機能の詳細はこちらのページで確認できますし、こちらのブログで丁寧に紹介されているので、ここではできることを簡単に箇条書きでまとめるにとどめておきます。

WordPress 用 Code Style

WordPress 用 Code Style が用意され、WordPress のコーディング基準に従ってフォーマットされます。 既存のコードに適用するには「Reformat Code」ですね。

フック (filter/action) 名称のの入力補完

WordPress Core で宣言されているフック名を入力補完してくれます。

フックの呼び出し箇所へのジャンプ

例えば、

add_action( 'admin_init', 'my_hook' );

というコードを書いているときに行頭カラム内のアイコンをクリックすると、

do_action( 'admin_init' );

というようなフックの呼び出し場所へ一発で飛ぶことができます。

フック関数へのジャンプ

上の例で add_action の例で ‘my_hook’ の部分を Ctrl + マウスクリック をすることで ‘my_hook’ の宣言箇所へジャンプすることができます。 クラスメンバ関数をフック関数として登録している場合もちゃんと飛んでくれました！

WordPress.org 内の検索

関数名などの文字列を選択した後のコンテキストメニューより「Search on WordPress.org」を実行できるようになりました。 なお、検索結果は新しい開発者ポータルである developer.wordpress.org のページが表示されます。 (developer.wordpress.org に関する情報はこちら)

WP-CLI の統合

WP-CLI を Command Line Tool Console から使うことができます。 各種オプションの補完も効きます。 WP-CLI そのものについては公式サイトや「サイトの拡張性を飛躍的に高める WordPressプラグイン開発のバイブル」をどうぞ。

ついでに紹介 – JetBrains Open Source License

PhpStorm の開発元 JetBrains からオープンソース開発者向けに Open Source License という無償ライセンス提供プログラムが提供されています。 開発プロジェクトの情報 (公式ホームページ、開発レポジトリやフォーラムの URL 等) を送り審査を受けて基準が満たされていればライセンスが発行されます。 英語でのやりとりとなりますが、WordPress.org に自作品を登録しているプラグイン開発者であれば英語にも慣れているでしょうし、入力項目としても WordPress.org のレポジトリやサポートフォーラムを伝えればよいのでそれほどハードルは高くないと思います。 興味のある方はどうぞ。

Thin Out Revisions 1.7 をリリースしました。このバージョンではリビジョンメモ機能が強化され、投稿にリビジョンメモを表示できるようになりました。 余裕がなくて日本語リソースができていないのですが、その分この記事で説明しておきます。

以下のようなパラメータが TOR の設定画面に追加されています。 「On」を選ぶとこの機能が有効になります。 また、デフォルトの状態を「Show」(表示) とするか「Hide」(隠す) とするかを選択できます。

個別の投稿設定で「Show」、「Hide」を選ぶこともできます。 こちらの設定が優先されます。

メモを表示する場合もその投稿の一部のメモを隠すことができます。 先頭に「#」(半角) をつけてください。

上のメモがあるときに投稿上のメモ表示は下の通りになります。

メモ自体は DL としてマークアップされます。 DL の前の見出しは設定画面で入力できますが、いくつかのタグ (<script> 等) は使えません。 入れても削除されます。

リビジョンメモ機能もリビジョン削除機能に劣らず便利なので、是非使ってみてください。 まだ更新できていない日本語公式ページはこちら (苦笑)。

WordPress プラグイン作者としては買っておかねばと思い、先月発売された「サイトの拡張性を飛躍的に高める WordPressプラグイン開発のバイブル」を買いました。 一応プラグイン作者なので知っていることも多いためざっと読んだだけですが、感じたことをまとめておきます。

• プラグインをつくるために必要な知識が一通りまとまっています。 面白いと感じたのは、技術的な面だけでなくライセンスや収益モデルなどビジネス的な側面に関わることもまとめられていることです。
• 私はプラグインの作り方を洋書で学びましたが、これからプラグイン作成を行おうとする方には間違いなく本書の方がお勧めです。
• 強いて挙げるならば、Ajax 関連と Cron 関連もあると良かったかも知れません。
• ただし、WordPress のコアの部分の解説は本書の範囲ではないので、そこは期待してはいけません。

どれぐらいの数の日本人がプラグイン開発に興味を持っているのかが想像できないのですが、興味があれば是非本書を手に取っていただきたいところです。

以下は私の個人的な意見や補足です。

• 公式レポジトリへプラグインを登録し、ある程度メンテナンスもしていこうと考えているのであれば、情報としては日本語サイトではなく本家を参照するようにしましょう。
• 怖がらずに英語でメッセージやドキュメントを書き、サポートも WordPress.org 内に用意されるそのプラグイン用サポートページを第一の場にするといろいろなものが得られるはずです。
• 私は紙の本を買いましたが、Kindle で慣れているのであればそちらの方が検索したりするのには便利かも。 もう少し Kindle 版が安くなればなあ…。
• gettext については msgmerge を知っていると良いかも。私の書いた記事はこちら。
• 公式リポジトリへの登録には subversion が必要ですが、普段は GitHub を使っていて WordPress.org への登録のみ svn という人も多いようです。 そういう人は大抵最新ファイルをコピーして svn commit するスクリプトを使っているようです (検索すればサンプルが見つかるはず)。 ちなみに私は git-svn 派ですが、ちと面倒なので少数派です。もし、git-svn で行くのであればこちらの記事を参考にしてください。
• 本書のコラムにもありますが、Settings API について学習すると良いと思います。 ちなみに私のプラグインでは、管理画面で入力された値のチェックは admin_init のコールバック関数内で行うのではなく、Setting API に含まれる register_setting() の第 3引数で指定する関数内で行っています。 このチェックでエラーがあった時は add_settings_error() を呼ぶようにしています。

何にせよ、本書の影響で日本人が作ったプラグインが公式リポジトリにもっと登録されるようになれば良いと思います。