チャットサポートを構築する (その2) サーバー ejabberd の準備

【2018年4月20日追記】この記事は内容が古くなっている部分があります。「あらためてチャットサポートを構築する」もご覧ください。【追記ここまで】

前回の「チャットサポートを構築する (その1)」は、Converse.js を設置し、(テストのページ)のように、普通の XMPP クライアントとして使えるというところまででした。

BOSH サーバー

ここからしばらく、サーバー側の設定の話になります。

クライアントが Converse.js などウェブベースのもので内部状態を保持できないような場合、BOSHという仕組みを介することで、接続を維持します。XMPP サーバーの ejabberd の場合、設定ファイル ejabberd.cfg次のように書くことで、BOSH サーバーにもなります[1]

ポート 5281 (HTTPSの場合)を listen するところに http-bind と書き足します。

{listen,
 [
  ...
{5281, ejabberd_http, [
       ...
       http_bind,
       ...
       ]}
  ...
]}

モジュールの設定のところで

{modules,
 [
  ...
  {mod_http_bind, []},
  ...
]}

を読み込むようにします。

匿名サーバー

XMPP サーバーには匿名サーバーという機能を持つものがあります。一般にクライアントがサーバーに接続する場合、事前に登録して作成しておいた user@example.net という形をした JID と、パスワードが必要になりますが、匿名サーバーは、そのサーバー名だけを指定して接続を試みると、@ より前のユーザー名を乱数のようにそのつど生成して接続します。

サーバーアプリケーション ejabberd の場合、ejabberd.cfg につぎのように設定して SASL 匿名サーバー (anonymous.example.net という名前だとします) を設置します。

{hosts, [ ..., "anonymous.example.net"]}.

{host_config, "anonymous.example.net", [
                               ...
                               {auth_method, anonymous},
                               {anonymous_protocol, sasl_anon},
                               {s2s_default_policy, deny},
                               {{s2s_host,"example.net"}, allow},
                               ...
]}.

s2s_... は、匿名サーバーに接続したユーザーは特定のサーバー以外への通信を禁止するという設定です。

クライアント側の事前接続

ここからクライアント側の話です。

「チャットサポート」として利用できるためには

  1. アプリケーションの事前インストールが不要
  2. アカウント(JID)の登録が不要
  3. 連絡先が登録済み

であることが必要です。前回はこの最初の項目、Converse.js をごくふつうに設置する(テストのページ)ところまで行いましたが、このままでは客側にアカウント (JID) を入力してもらわなければなりません。

Converse.js のマニュアルに Server-side authentication という章があります。別の何らかの方法で事前にサーバーに接続しておき、その情報を引き継げば、上述の2番めの項目をクリアできます。接続先を匿名サーバにすればパスワードも不要になります。しかし、マニュアルには具体的な方法はありません。

次のような方法を考えてみましたがこれで正しいのかよくわかっていません。とりあえず(ある場合には)うまくいっています。もし詳しい方がありましたら、ぜひ教えてください。

Converse.js の初期設定を書く <script> のところの先頭に書き足します。

<script TYPE="text/javascript">
var BOSH_SERVICE = 'https://anonymous.example.net:5281/http-bind';
conn = new Strophe.Connection(BOSH_SERVICE);
conn.connect('anonymous.example.net', '', onConnect);

function onConnect(status)
{
     wpCookies.set('jid', conn.jid);
     wpCookies.set('sid', conn.sid);
     wpCookies.set('rid', conn.rid);
}

Strophe.js は Converse.js に同梱されているので、Converse.js を利用できるようにしていれば、使えます。接続すると JID、SID、RID が確定するので、それをクッキーとして書き出します。ここでは WordPress の wp-include/js/utils.js を利用した記述 wpCookies.set になっていますが、もちろんそれでなくてもかまいません。

それに続く Converse.js の設定では

require(['converse'], function (converse) {
    converse.initialize({
        ...
        bosh_service_url: BOSH_SERVICE,
        prebind: true,
        jid: wpCookies.get('jid'),
        rid: wpCookies.get('rid'),
        sid: wpCookies.get('sid'),
        ...
    });
});
</script>

と、bosh_service_url を指定し、prebindtrue とし、jid, rid, sid をクッキーから読み込みます。

この項まだ続く

  1. BOSH サーバーには2種類あります。local BOSH サーバーは、入り口はどこからでも接続できますが、ローカルのアカウントにしか接続できません。それに対して open BOSH サーバーは、他所のサーバーのアカウントにも接続できます。ejabberd の BOSH は local タイプです。

チャットサポートを構築する (その1)

【2018年4月20日追記】この記事は内容が古くなっている部分があります。「あらためてチャットサポートを構築する」もご覧ください。【追記ここまで】

ずっと頭の片隅にあっていつかはと思っていた話題ですが、あたためすぎて腐ってしまった感なきにしもあらずです。何しろ自分でプログラムを書くほどの能力がないので、道具が出揃うのを待っているうちに随分時間が経ってしまいました。

「チャットサポート」というものについて考えてみます。Wikipedia の記述をそのまま引用しますが、

文字通り、チャットによるサポートであり、閲覧中のWebページ内のチャットボタンをクリックするだけでリアルタイムに Web サイト運営者のサポートをリアルタイムに受けることが出来るシステム。……英語ではLive Chat Supportと呼ばれることが多い。

というものです。アメリカのネット通販サイトなどではよく目にしますが、日本ではあまり見かけません。それでも「チャットサポート」で検索すると、日本(語)でもそのようなサービスを提供するところが増えてきているようです。

しかし大手の販売サイトならともかく、月に数回程度の利用しかないと想定される規模では、月額数千–数万円のサービス料金がメリットに見合うとは、あまり思えません。

そこですべてオープンソースの個々の汎用アプリケーションを組み合わせて、無料でこの仕組みを構築することを考えてみました。プログラムを書く能力があれば自分で作れるのでしょうが、それができないために、あちこちのソフトを組み合わせることになりました。

基本はチャットですから、XMPP を使います。このプロトコル自体がオープンであり、Skype や LINE や twitter などとは異なります。

すべてオープンソースの組み合わせで構築すると

  • 費用が発生しない
  • 独占企業の都合によるサービスの変更や停止ということがない
  • 個々のアプリケーションを取り替えられる
  • カスタマイズできる
  • サーバーも自分で管理すれば他者を経由しないので情報の流出の不安がない

などのメリットがあります。

もちろん逆に、一定の労力が必要だったり、汎用アプリのため洗練されていないなどのデメリットもあります。

通常のチャットでは、話者のそれぞれが XMPP のアカウント(JIDといいます)を持ち、互いに相手先を名簿に登録しており、それぞれ手元の端末にインストールするなりした XMPP のアプリケーションを使って、サーバーを介して会話します。「チャットサポート」の場合、サポートする側(問い合わせを受ける側。以下、便宜的に「窓口側」と呼びます)は別として、一度きりかもしれない問い合わせを行う側(以下、「客側」と呼びます)に、そのためにアカウントやアプリケーションを用意してもらうことは非常に難しいでしょう。

Converse.js

まず XMPP クライアントアプリケーションですが、JavaScript で書かれたものをウェブページに設置することで、そのページにアクセスするだけで利用できるようにします。これで、客側が事前にアプリケーションをインストールしなければならないということがなくなります。

Converse.js というものを見つけました。2014年初頭現在、活発に開発されているようです。多言語化されているようですが、日本語はまだ対応していなかったので、翻訳して作者に送ってみました。この時点で日本語での情報はほとんどなく、見つけたのは「Ejabberd+Apache mod_proxy+converse.jsでXMPP(BOSH)なチャット環境を作ってみた」でした。

さて、マニュアルに従って設置してみます。<head>内に CSS と本体の js を読み込むように書き、またページ後半に初期設定を記した <script> を書きます。ここまでは簡単で、そのまま Converse.js が使えるようになりました。

テストのページで実際に見てみるとわかるように、素のままでは普通の XMPP クライアントとかわりません。すなわち、自分のアカウント情報を入力し、相手先のアカウントを指定して会話を開始する、というものです。

長くなりそうなので、この項続く

生活の柄

このブログを継続的にに読んでいる人はほとんどいないだろうから、わざわざ書かなくてもいいのだけれど、それも気が引けるので、そっと書いておきます。

1年ほど前に、2人暮らしになったと、これからどんな暮らしになるのだろうと不安混じりに書きましたがそれから1年、また元の3人暮らしに戻りました。ひとり親家庭のことやこどものことなどをここに書いていけるのかな(自分のそのとき、いろいろ検索して調べまわったので)と思っていましたが、生の出来事をそのままというわけにもいかず、ほとんど何も書けませんでした。まあこどもの成長のことはこれからも少しづつ出していけると思いますけれども。

ともあれ、なんとかこうして生きています。

第何何曜日 再び

昨年末に「2013年に読まれた記事トップ10」を書く際にサイト統計を見たのですが、圏外すぐに「第何何曜日」がありました。古い記事ですが、それなりによく読まれています。

ところでいま調べなおしてみたら、PHP の strtotime() には便利な機能があるではありませんか。前の記事を書くときには見落としていたのか……。前の記事の脚注を見ると PHP 4 と書いているから、まだ使えなかったのかな。

というわけで、いま風に書き直してみます。

Y 年 m 月の第 i の w 曜日は、その月の d 日か

PHP ならこれはもう簡単で、そのまま書くだけです。

Y, m, i, w という記号では書きにくいので、具体的に「2013年12月の第3木曜日」を例にすると、

$d = date("d", strtotime("third Thursday of Dec 2013"));

です。「今月の第3木曜日」なら “third Thursday of this month” ですし、「次の第3木曜日」なら “third Thursday” だけです[1]。なんて簡単なんだ。

ここに日本語が使えると便利なのですが、さすがにそこまではできないようです。というのは、「おととい」を指定するのが、英語だと “day before yesterday” で、まどろっこしいからです。日本語だと今日の前後2日までは短い言葉があるのに[2]、英語だと前後1日までで、その先は持って回ったような言い方になってしまいます。話はやや違いますが、PostgreSQL の SQL でも “today”, “yesterday”, “tomorrow” のキーワードは使えるのですが(ほかの DB はどうなんでしょう?)、「おととい」をしょっちゅう入力したい私はしかたなく日付を使っていて、どうにかしたいなあと思っているのでした。

さて、前の記事の際の動機はゴミの収集日でした。「第 2, 4 月曜日」だとすると、次のゴミの日は

$gomi = date("Y-m-d", min( strtotime("second Monday"), strtotime("fourth Monday") ) );

で済みます。

ちょうど当該日にこれを実行すると、その日になります。しかしゴミの収集時刻 14:00 を過ぎていたら次の収集日を出力してほしいですね。

$base = ( date("G") <= 14 ) ? strtotime("today") : strtotime("tomorrow");
$gomi = date("Y-m-d", min( strtotime( "second Monday", $base ), strtotime( "fourth Monday", $base ) ) );
}

ちょっときれいじゃない気がするけど、こんなのでいいのかなあ。

  1. なお、この書式でも「第5週」の場合は注意が必要です。
  2. その先も「さきおととい」とか「しあさって」あたりまでは、たまに耳にします。

WordPress のプラグインを公式リポジトリと GitHub に公開する

昨年末に公開したプラグイン wp_mail to XMPP は、Git で管理しつつ作ってみました。ひととおりできたところで GitHub に公開。それから公式リポジトリを申請して、こちらは SVN なので、git-svn で送ろうとしてもなんだかうまくいかず、とりあえず手動で(ローカルの別の場所にコピーして、svn で。つまり Git とは完全に切り離して)作業しました。

それからゆっくり見なおしてみました。

WordPress公式プラグインリポジトリに登録しているプラグインをGitHubで管理する」や「公式リポジトリのWordPressプラグインをGitHubでバージョン管理できる『wp-plugin-in-github』使ってみたよ」を見て、これは便利そうだと思ったのですが、tai さんと同じく readme と本体のバージョンが合わないエラーとか、

  • 手元で、勉強がてら git flow を導入していたので、そのままでは構成が合わない
  • 翻訳ファイルの作業は自前の Makefile と重複する

など、そのままでは使えませんでした。そこでその中身を個々にやるような形ですが、次のようにやってみました。参考にしたページは

です。

手順

出発点は

  • 既に公式リポジトリに何らかがある状態
  • 公式リポジトリの branches は使っていない
  • 手元では git-svn がインストールされている状態

という中途半端なところなので、どれほど意味があるのかわかりませんが、自分のメモとして。そのため、例とするプラグインは wp_mail to XMPP です。

公式リポジトリと連携

まず、trac で見るなどして、はじめと終わりのリビジョン番号を調べておきます。

それと、内容が

mako09 = Mako N <mako@pasero.net>
plugin-master = Mako N <mako@pasero.net>

というファイル(名前は何でもいいですが、ここではauthor.txt とします)を作っておきます。

次に、ローカルの何もない場所で、

git svn clone --no-minimize-url -s -A author.txt -r829275:829448 http://plugins.svn.wordpress.org/wp-mail2xmpp/

を行います。-r(はじめ):(終わり)を付けます。この -r ではじめと終わりを指定すれば膨大な時間がかかることもありません。-r(はじめ) だけでは、はじめのリビジョンは申請によって向こうで(plugin-masterに)場所だけ作ってもらったものなので、空っぽのディレクトリだけになります。

手元で作業していた git リポジトリで、このコマンドを実行してもうまくいきませんでした。これ自体はうまくいっているように見えるのですが、後段の git svn rebase が “Unable to determine upstream SVN information from working tree history” と言うのです。何もない場所でやるとうまくいきます。

git の設定

git config user.name などの設定を行います。git flow を使うため、

git flow init

も行います。

ブランチの作成

git checkout -b svn

で、svn という名前のブランチを作ります。

svn → 公式、master → gitHub で、develop は手元、という構成です。svn と master の違いは、今回の例では公式には置かないファイル(Makefile, LINGUAS)だけです。

git svn fetch
git svn rebase

で、同期させておきます。

ローカルから取り込み

既に作業していたローカルのリポジトリから

git checkout master
git remote add temp file:///...
git pull temp master
git checkout develop
git pull temp develop
git remote remove temp

で、取り込みます。

GitHub との連携

git checkout master
git remote add origin git@github.com:mako09/wp-mail2xmpp.git

として、

git pull origin master

で、同期させておきます。GitHub には何もなくてこれからという場合は、むしろ git push することになります。

以上で、GitHub とも公式リポジトリとも連携した git リポジトリが手元に出来ました。これまで作業してきた手元の git リポジトリは不要になります。

その先に作業してきた git リポジトリに、git-svn で svn リポジトリを連携させることができればよかったのですが、上述したようにうまくいきませんでした。このへんの仕組みはよく理解できていません。そのため、このようなとてもまわりくどい手順になってしまいました。

以後の作業

以後は、手元の git リポジトリで作業します。master が完成したら(git checkout master の状態)、GitHub に送ります。以下、まだその場面ではないので十分試していませんが、

git push           # GitHub に送られる

続いて、ブランチ svn に移って、svn に送ります。

git checkout svn
git merge master   # --squash をつけるか、merge ではなく個々のファイルを checkout のほうがいいかも
git svn fetch      # 念のため
git svn rebase
git svn dcommit    #公式リポジトリに送られる

git のタグは(ブランチ master で)

git tag 0.9

のようにします。これを GitHub に送るには

git push origin 0.9

です。

svn にタグをつけるのは(ブランチ svn で)

git svn tag 0.9

のようにします。メッセージは自動的に “Create tag 0.9” のようになります。このコマンドで公式側にタブができます。

2013年に読まれた記事トップ10

流行っているみたいなので、自分のところでも見てみました。Jetpack のサイト統計情報の1年分です。

2012-12-31 to 今日

  1. gdm でのシャットダウンの禁止 (2007年10月)
  2. GNOME でのシャットダウンの禁止—最近の流儀 (2011年6月)
  3. 2台所有する自動車の1台を手放すとき、保険は等級の高いほうを残すことができる (2013年2月)
  4. WordPress 3.6 日本語版 (2013年8月)
  5. WordPress: フィルターより前にショートコードを実行させる (2013年3月)
  6. wp-login.php への攻撃に対処する (2013年9月)
  7. 公開 Jabber/XMPP サーバー (2011年7月)
  8. 日本語スタイルガイド項目別比較一覧表 (2012年3月)
  9. ja.po のコメント欄に見る WordPress 日本語版の歴史 (2013年5月)
  10. Jabber と WordPress (前編) (2010年11月)
  11. Firefox に新しいプロトコルを教える (2012年2月)

1位の記事はとても古くて、そこから誘導している改訂版みたいな内容が2位なので、これらは実質同じもの。この情報は公式に近いところに見られないのでこちらに来ているのでしょうか。こういうちょっとした設定をしたいのにとてもわかりにくい GNOME の傾向はなんとか変わってくれないものかと思います。

3位の自動車保険の話も、意外と他所では見つけにくい情報なのでしょう。

4位の WordPress 日本語版リリースリーダーの話は、twitter や facebook で広めてもらった(自分の記事としては)ようです。

5位は、いまこのリストを見て自分でも意外でした。これも他所にはあまりない情報なのかなあ。

7位と10位は古い記事ですが、Jabber/XMPP の情報は日本語ではとても少ないので、ここにたどり着くのでしょう。公開サーバー STEP.im をよろしくお願いします。

9位は、WordPress 10周年に寄せて書いたものです。

1位と2位が実質ひとつなので、11位まで掲載しました。

このブログを継続的に見ている人はたぶんほとんどなく、検索でその記事だけ単発にたどり着くのが大部分だと思っています。あたりまえのことですが、他所にない情報がよく見られているということですね。来年もそんな記事をいくつか書ければと思います。

WordPress からのほぼすべての通知を XMPP で送信するプラグイン wp_mail to XMPP

先日、WordPress のフォーラムの話題に触発されて、「コメントが来たことをメール以外で知らせる方法」という記事を書きました。

そのあともう少し一般的に考えてみました。WordPress から多くのメールが届きますが、そのほとんどは単なる「通知」で返信を要しないものです。つまりメールである必要はないのです。ということは、コメントがついた時だけでなく、WordPress からのすべてのメールを XMPP にしてもいいのではないか、と思いました。メールと XMPP は形式がとてもよく似ており、そのまま宛先を変えるだけでいいのではないか、と。

探してみたら、同じ目的の XMPP sender というものが既にありました。しかし中を見てみると古くて、メンテナンスもされていないようです。また、完全に wp_mail() を置き換えているので、条件によっては XMPP ではなくメールで送りたいと思っても応用が効きません。

WordPress からの通知は、更新・ユーザー追加・コメントなど発生源は種々あっても最終的には wp-includes/pluggable.php の中の wp_mail() によってメール発信が行われています。[1] wp_mail() を見てみますと、

function wp_mail( $to, $subject, $message, ...) {
	extract( apply_filters( 'wp_mail', compact( 'to', 'subject', 'message', 'headers', 'attachments' ) ) );
		...
		$phpmailer->Send();
}

という構造になっています。冒頭のフック ‘wp_mail’ は、たぶん送信先の追加や、subject(件名)や message(内容)に一律に何か加工するなどを想定されていると思いますが、その中で XMPP 送信を行ってしまえばいいと考えて、次のようなプラグインを作りました。

wp_mail to XMPP
Send almost all notifications via XMPP instead of email

https://github.com/mako09/wp-mail2xmpp にも置いてあります。

前の記事「コメントが来たことをメール以外で知らせる方法」でざざっと書いて示したプラグインは、その機能が今回のプラグインに完全に含まれますので、忘れてください。

なおこのプラグインは、別のプラグイン XMPP Enabled を利用していますので、それを先にインストールしてください。

きっかけとなったフォーラムの話題のように、複数の投稿作成者がいて誰かが投稿したことを他の作成者たちが知りたい、という場合には、投稿を通知するプラグイン(公式ディレクトリで “post notification” で検索すれば、いろいろ見つかります)、たとえば New Post Notification などをインストールしておけばいいでしょう。そのメール通知も今回のプラグインで XMPP に振り替えます。

wp_mail to XMPP の中身

このプラグインは2つのフックを備えています。

abort_xmpp_sender は、XMPP送信処理を中止するためのものです。たとえば「コンタクトフォームからの送信は、JID の有無に関わらず、メールで送信する」としたい場合、件名やヘッダなどで判定するフィルターを追加すれば、実現できます。

email_to_jid は、メールアドレスから JID に変換するフィルターを呼び出します。デフォルトでは、そのサイトに登録されているユーザーかつそのユーザーがJIDを設定している場合のみ、JID を返すフィルターを設定しています。たとえばコメントをつけた人が入力したメールアドレスのように、JID を見つけることができなければ、その人には XMPP 通知を出しません。このフックにさらにフィルターを追加して、たとえば JID があっても XMPP 通知を出さない人を設定する、あるいは逆に、JID が見つからない場合は管理者の JID に XMPP 通知を出す、などを実現できます。

これらの後に、JID があれば XMPP 通知を、JID がなければメール通知を行います。XMPP に送られる通知では、subject(件名)と message(内容)をそのまま用い、headers(ヘッダー)と attachments(添付)は送信せず無視しています。

オプションで、XMPP 通知を行ったユーザーにもメール通知を行うように設定することもできます。

おわりに

はじめてプラグインを公式に公開しようとしたら、実際に動作するコードの部分を書く時間の10倍くらいを、その周辺のことに費やしました。名前を決めること、コメントや readme を英語で書くこと、依存する別のプラグイン XMPP Enabled を国際化・日本語化して作者に連絡して取り込んでもらうこと……。いやはや、いい経験になりました。それでもコード自体にも英語にも自信がありません。おかしなところを見つけて知らせてもらえたらうれしいです。

  1. ただし Jetpack購読(subscription)は、実際には WordPress.com がメールを送信しているため、これに該当しません。