ke-tai.org ケータイサイト開発に関わる記事・情報を紹介

先日ご紹介した「インプレスR&Dの携帯機種の詳細スペックデータ」を、自動でダウンロードするためのシェルスクリプトを書いてみました。

このスクリプトをcronなどに登録することで、毎日自動でCSVをダウンロードするといった仕掛けを構築することができます。

#!/bin/sh

# ユーザ名とパスワードを設定
user='[インプレスR&Dから通知されるユーザ名を設定]'
passwd='[インプレスR&Dから通知されるパスワードを設定]'

# URLやファイル名などを設定
url='[インプレスR&Dから通知されるURLを設定]'
filename='profiledata.zip'
dirname='ProfileData'

# CSVファイル名の接頭語を設定
csv=('DisplayInfo' 'ProfileData' 'UserAgent')

# リストをダウンロード
wget --http-user $user --http-passwd $passwd $url

# 展開
unzip $filename

# CSVファイルの日付部分を削除するようにリネーム
for target in ${csv[@]};
do
  mv $dirname/$target* ./$target.csv
done

# 一時ファイルを削除
rm $filename
rm -rf $dirname

使い方は、上記をシェルスクリプトとしてファイルに書き、利用申し込み時にインプレスR&Dから送られてきた、ユーザ名・パスワード・URLをセットし、実行するだけです。

ダウンロードにはwgetを、解凍にはunzipを利用していますので、入っていない方はインストールするか、他のソフト（例えばcurlなど）を利用するようにしてください。

シェルスクリプトはほとんど書かないため、あまり良くない書き方をしているかもしれませんが、もしより良い方法がありましたらご指摘をお願いします。

関連：

• インプレスR&Dが携帯機種の詳細スペックデータを無償提供
• PHPでケータイのFlash対応・非対応を判定できる関数を作ってみました
• ケータイスペック一覧ページをリニューアルしました

Apacheのアクセスログから、携帯電話のユーザエージェントを抽出し、機種別のアクセス数を表示する1行コマンドを考えてみました。

正確な分析はアクセス解析ソフトに任せるとして、パッと機種別のアクセス数が知りたい場合に使えるかもしれません。

ドコモ用

$ perl -na -F/'(DoCoMo\/.\.0.*?)(\/c|\()'/ -e 'print $F[1]."\n"' access_log |grep -v "^$" |sort |uniq -c |sort -r

au用

$ perl -na -F/'(KDDI\-.*?)"'/ -e 'print $F[1]."\n"' access_log |grep -v "^$" |sort |uniq -c |sort -r

ソフトバンク用

$ perl -na -F/'((SoftBank|Vodafone|J\-PHONE|MOT\-)\/.*?)"'/ -e '$F[1] =~ s/SN([0-9]{15}|[0-9A-Z]{11})/\[ \/Serial\ ]/;print $F[1]."\n"' access_log |grep -v "^$" |sort |uniq -c |sort -r

*1　表示の都合上改行していますが、実際には1行で入力します。
*2　Apacheのログはcombined形式を前提としています。
*3　上記例ではApacheのログは「access_log」という名前としています。必要に応じて変更してください。
*4　auのHDML機は対象としていません

次のようにUAが抽出され、アクセス数順に並びます。

また、パイプ以下を「|grep -v "^$" |sort -u」とすれば、アクセスのあった機種を、名前順にリストアップすることができます。
このリストをDBと比較するプログラムを作成し、ケータイスペック一覧ページの抜けチェックに利用しようと思います。

perlはあまり得意ではないので、もっと綺麗に書けそうな感じがします。。。
より良い書き方がありましたら、ご指摘をお願いします。

mod_chxjは、ユーザエージェントから端末を判断し、絵文字や画像の3キャリア変換を自動処理するApacheモジュールです。

先日のこちらの発表で、なぜか今頃になって注目を浴びつつあるこのソフトをインストールしてみました。

mod_chxjは、2006年7月のバージョン0.8.0からリリースがありません。
今後、メンテナンスされるかどうかも不明で、端末データも古いです。
今回はとりあえず評価目的ということで、インストールから動作するところまでご紹介しようと思います。

こちらのサーバの環境としては、
「CentOS5 + Apache2.2(httpd-2.2.3-11.el5.centos)」
となっています。環境が違う方は適宜読み替えてください。

ドキュメントはこちらにありますので、これに沿って作業していく形になります。
→　mod_chxj ドキュメント [sourceforge.jp]

まずは動作に必要なソフトをインストールします。
ドキュメントによると次のものが必要なようです。

mod_chxjをインストールする前に、下記のものを用意する必要があります。
1. Apache2.0のヘッダーファイル群
2. Apache2.0用のapxs
3. apr(Apache Portable Runtime)ライブラリとそのヘッダファイル郡(apu含む)
4. automake、autoconf、libtool1.3.X
5. ImageMagick(MagickWand)
6. libiconvまたはlibiconv_hook

yumを使って順にインストールしました。

# yum install httpd-devel
# yum install automake autoconf
# yum install libtool
# yum install ImageMagick
# yum install ImageMagick-devel
# yum install pcre-devel

libiconvはyumになかったため、こちら [gnu.org]からダウンロードしてインストールしました。

$ ./configure
$ make
# make install

さてこれで準備が整ったので、次はmod_chxj本体のmakeなのですが、私の環境ではApache2.2系を使っているため、このままコンパイルしても通りません。
2.2系を使っている場合は、先にパッチを当てる必要があります。
2.0系の方はそのまま行けると思います。

パッチはこちらのサイトを参考に作成させていただきました。ありがとうございました。
→　Devel::Bayside　mod_chxj を Apache 2.2 で動かす [hatena.ne.jp]

パッチのダウンロードはこちらからどうぞ
→　mod_chxj-0.8.0_apache2.2_patch.tar.gz　[ke-tai.org]

$ tar xvfz mod_chxj-0.8.0.src.tar.gz
$ cd mod_chxj-0.8.0

※以下Apache2.2系の方のみ
$ patch src/mod_chxj.c < ../mod_chxj.c.2.2.patch
$ patch src/chxj_cookie.c < ../chxj_cookie.c.2.2.patch

mod_chxjのコンパイルとインストール

$ ./buildconf.sh
$ ./configure --with-apache-header=/usr/include/httpd/
--with-apr-config=/usr/bin/apr-1-config
--with-apu-config=/usr/bin/apu-1-config　※実際には1行で実行
$ make
# make install

CentOS5の場合は、なぜかaprとapuに「-1」がついていたため、上記のオプションをつけました。
環境によっては不要になると思います。
詳しくは「./configure --help」でご確認ください。

これで「/usr/lib/httpd/modules/mod_chxj.so」にモジュールがインストールされました。
続いて端末データと絵文字データの置き場所を作り、データコピーします。

# mkdir /etc/httpd/chxj
# cp etc/device_data.xml /etc/httpd/chxj/
# cp etc/emoji.xml /etc/httpd/chxj/

mod_chxjの設定ファイルを作成します。

# vi /etc/httpd/conf.d/chxj.conf

内容は次のようにしました。詳しくはmod_chxjのドキュメントページをご覧ください。

# Load module mod_chxj
LoadModule chxj_module /usr/lib/httpd/modules/mod_chxj.so

# Device data
ChxjLoadDeviceData  /etc/httpd/chxj/device_data.xml

# Emoji data
ChxjLoadEmojiData   /etc/httpd/chxj/emoji.xml

設定が正しいか確認します。

# apachectl configtest

ここで、
httpd: Syntax error on line 210 of /etc/httpd/conf/httpd.conf: Syntax error on line 2 of /etc/httpd/conf.d/chxj.conf: Cannot load /usr/lib/httpd/modules/mod_chxj.so into server: libiconv.so.2: cannot open shared object file: No such file or directory
のようなエラーが出る場合は、libiconvのライブラリが読み込めていない可能性があります。

ひとまずシンボリックリンクを張ってごまかしましょう。
（何かスマートな方法がありましたら教えてください）

# ln -s /usr/local/lib/libiconv.so.2 /usr/lib/

エラーが出なくなったらApacheを再起動します。

# apachectl configtest
Syntax OK
# /etc/init.d/httpd restart
httpd を停止中:                                    [  OK  ]
httpd を起動中:                                    [  OK  ]

これで動作準備OKです。

続いてmod_chxjの設定を書きます。
httpd.confに書いても良いのですが、私は.htaccessに書くことにしました。
mod_chxjを動作させたいディレクトリに、次の内容で.htaccessを置きます。

<IfModule mod_chxj.c>
  ChxjConvertRule     ".+$" "EngineOn" "NONE"
  ChxjImageEngine     On
</IfModule>

HTMLを設置しケータイから確認すると、確かにドコモからは見れないはずのPNG画像が表示されています。
またソフトバンクでは絵文字の変換も行われているようです。

関連：

• ゆめみ、3キャリア対応用のApacheモジュール「mod_ktai」を開発中

今回は、ケータイ上からPHPのセッションを使う場合の設定方法についてです。

ケータイからPHPのセッションを機能を使う場合、端末によってはクッキーが利用できない場合があるため、そのままでは使うことができません。

セッションを使いたい場合は、インストール時のconfigureオプションに、「--enable-trans-sid」を付ける必要があります。
※Windowsの場合は特に設定の必要はありません。

また、「php.ini」の設定で、次のように設定してください。
※設定変更後はWebサーバの再起動が必要です

session.use_trans_sid = 1

もしくは「.htaccess」でも設定することができます。
※.htaccessでの設定上書きが許可されている場合のみ

php_flag session.use_trans_sid On

設定変更は、phpinfoで確認できます。

PHPのコード内で、

ini_set('session.use_trans_sid', '1');

でも設定できますが、その場合は「session_start();」より前に実行する必要があります。

設定が有効になると、リンクの後ろに自動でセッションIDが付加され、セッション変数が引き継げるようになります。
※ただしクッキーが使える端末で、「session.use_cookies On」の場合には、セッションの管理にはクッキーが優先して利用され、URLにセッションIDはつきません。

セッションIDが付加された例：

<a href="index.php?PHPSESSID=b37b5e8e31118c45e19a5fb6b70c215a">
トップへ
</a>

ページの移動に静的HTMLを挟んだり、引数をつけないでリダイレクトしたりすると、セッションは切れてしまいますので注意が必要です。

※セッションハイジャックに対する注意書きが足りないとのご指摘を受けましたので追記しました。失礼しました。

上記設定のままですと、URLに固定のセッションキーがついたままの状態のため、リンク先のページにRefererが漏れてしまったり、友達へメールでURLを転送した場合などに、セッションハイジャックされてしまう可能性があります。
そこで安全度を高めるために、次のような対応策を平行して行うと良いようです。

※再度ご指摘を頂きました。iモードの端末はRefererを出力しないので、その場合はRefererを原因としたセッションハイジャックは考慮しなくてもよいようです。

1. クッキーを利用できる端末の場合は、そちらを利用する
2. 端末IDによる認証+IPアドレス制限を行う
3. session_regenerate_id関数を利用する

1については、auとソフトバンクの最近の機種ではクッキーが利用できます。
クッキーが利用できれば、URLにセッションIDを付加しなくてすみますので、URLからの漏洩を防ぐことができます。
セッションの管理にクッキーを優先して利用するには、「php.ini」または「.htaccess」で、「session.use_cookies On」と設定されている必要があります。

2の「端末IDによる認証+IPアドレス制限」については、まず.htaccessなどで、携帯キャリアのIPアドレスからのみアクセス可能な状態にします。
その状態でセッションに端末IDを格納し、アクセスの度に認証チェックを行うことでなりすましを防ぎます。
IPアドレスの制限をかけるのは、Refererが漏れている場合は、端末IDも同時に漏れているケースが多いためです。
端末IDはリクエストを偽造することで、なりすまされる可能性があるため、携帯実機からのアクセスのみとすることで安全度を高めます。

3の「session_regenerate_id関数」は、アクセスの度にセッションIDを変更するためのものです。
PHPのバージョンによって対処法が異なりますので注意が必要です。

まずPHP5の場合は簡単です。

PHP5でのセッションID再生成のサンプル

session_start();
session_regenerate_id(true);

session_regenerate_idの引数にtrueをセットすることで、古いセッションIDは破棄され、毎回新しいIDがふられます。

PHP4ではこの引数が利用できないため、古いセッションは破棄されず、同じことを実現しようとすると少し大変です。

PHP4でのセッションID再生成のサンプル

// セッション開始
session_start();

// 古いセッションを保存
$sess_tmp = $_SESSION;

// セッション変数を破棄
session_destroy();

// セッションIDを再生成
session_start();
session_regenerate_id();

// セッションを元に戻す
$_SESSION = $sess_tmp;

参考にさせて頂いたのはこちら[php.gr.jp]のページです。
欠点としては、アクセスの度にセッションファイルが作成されるため、ゴミファイルが残りやすいという点があります。

アクセスが多いサイトの場合は、ガーベージ・コレクションの設定をより頻繁にしたり、こちら[phppro.jp]やこちら[ishinao.net]のやり方を参考にすると良いかも知れません。

なお、session_regenerate_id関数を使うと、毎回セッションIDが変わるため、通信エラーが起こった際にセッションが切れてしまう可能性があるようです。
利便性を重視するかセキュリティを重視するか、扱う情報の重要度に応じて使い分けると良いと思います。
（詳しくはコメント欄をご参照ください）

※追記分について、まだセキュリティ上問題があったり、何か他に良い方法がありましたら、ご指摘をお願いします

ドコモ端末で2007/11/1から設定可能となった、新たな迷惑メール防止機能の「送信ドメイン認証（なりすましメール対策）」を、早速検証してみました。

送信ドメイン認証については過去の記事をご覧下さい。
→　 ドコモの送信ドメイン認証への対応について[ke-tai.org]

設定は、次の場所から行えます。

「iメニュー」→「[8]料金&お申込・設定」→「[3]かんたんメール設定」→「詳細な設定（メール設定）」

続いて、迷惑メール対策を押します。

なりすましメールに対する設定が増えています。
初期値は「拒否しない」になっています。まずは一安心です。

なりすましメールに対する説明はこんな感じです。

送信ドメイン認証に関する説明も記載されています。
一般の方には絶対わからないでしょうね。
　

実験のため「拒否する」にしてみました。

試しにSPFレコードが設定されていないドメインからメールを送信してみると、確かに送信されないようです。

具体的には、

Remote host said: 550 Unknown user [アカウント名]@docomo.ne.jp

という、550エラーが返ります。
このあたりの挙動は、今までの迷惑メール対策と同様ですね。

関連：

• ドコモの送信ドメイン認証への対応について