OpenPNE2.4.8がひっそりと公開。クリティカルなアップデートは特に無くて、微妙なレイアウト調整など。要のBIZモードに関するバグフィックスは、2.6系へ持ち越された感じ。

運営には全くと言っていいほど影響ないけど一応パッチを適応した。2.4系もそろそろ開発終了っぽいな。2.6系はバグだらけっぽいので、安定するまでは傍観の方向で。

関連エントリー：
OpenPNE2.4.6→2.4.7アップデート

OpenPNEの2.4.7が公開されたんで、恒例のパッチ当て作業。
BIZモードカレンダーのバグが直ってりゃーしないかと期待してたんだけど、今回も見送りになってた。がっくし。しょーがねぇんで自分で直してみた。

webapp_biz/modules/biz/lib/mysql_functions.php　537行

if (($begin_date < $testing) && ($finish_date > $testing)) {

↓以下に修正

if (($begin_date < $testing) && ($finish_date >= $testing)) {

webapp_biz/modules/biz/templates/fh_biz_schedule_calendar.tpl　116〜122行あたり

({elseif $item_schedule.begin_date != $item_schedule.finish_date}) <!–バナー予定 –>
({assign var=”begin_time_H” value=$item_schedule.begin_date|date_format:”%H”})
({assign var=”begin_time_M” value=$item_schedule.begin_date|date_format:”%M”})
({if $item_schedule.finish_time})
({assign var=”finish_time_H” value=$item_schedule.finish_date|date_format:”%H”})
({assign var=”finish_time_M” value=$item_schedule.finish_date|date_format:”%M”})
({/if})

↓以下に修正

({elseif $item_schedule.begin_date != $item_schedule.finish_date}) <!–バナー予定 –>
({assign var=”begin_time_H” value=$item_schedule.begin_time|date_format:”%H”})
({assign var=”begin_time_M” value=$item_schedule.begin_time|date_format:”%M”})
({if $item_schedule.finish_time})
({assign var=”finish_time_H” value=$item_schedule.finish_time|date_format:”%H”})
({assign var=”finish_time_M” value=$item_schedule.finish_time|date_format:”%M”})
({/if})

とりあえずなんとなく直ったっぽいけど、これが本来の仕様通りの動きなのかは不明。なんつーか、BIZモードの機能は全面的にリファクタリングが必要な気がするなぁ。2.6では改善されるんだろうか。

OpenPNEの最新安定版2.6がリリースされそうなので、玄箱で運用中のOpenPNEを2.2.10から2.4.6にアップデートした。

手順の大まかな流れは、1.9から2.2へアップデートしたときと同じだったので、比較的あっさり出来た。ひと足先に事務所のサーバーに2.4系をインストールしてあったので、カスタム済みのテンプレートファイルとCSSをコピーしておしまい。
微妙にハマりかけたのが、config.phpの

define(‘OPENPNE_USE_OLD_CRYPT_BLOWFISH’, false);

の部分を

define(‘OPENPNE_USE_OLD_CRYPT_BLOWFISH’, true);

にしておかないと、2.2系からアップデートした場合にログイン出来なくなる。config.phpを注意深く読んでいれば気がつくことだけど、こういう仕様変更はアップグレードガイドにも記載してほしいところ。

あと、Turck-MMcacheによるレビュー機能の不具合が再発、2.2だった時の回避策だと問題が解決できなくなっちゃった。後継のeAcceleratorに換えたほうがいいのかなぁ。

社内SNSとして、事務所のサーバーにインストールしたOpenPNE2.4.3をアップデートした。
デフォルトのまま運用している分には、OpenPNE tracで公開されてるパッチを

patch -p1 < OpenPNE_2_4_4_to_2_4_5.patch

すればおしまいなんだけど、かなりあっちこっちに手を入れちゃったので、仕方なく.patchファイルを見ながら該当箇所を書き換えた。

時々Timelineを巡回していられれば随時パッチ当ての作業してもそれほど面倒じゃないけど、忙しいとそうもいかない。OpenPNEを独自にカスタマイズしつつバグフィックスを取り込むウマイ手ってあるのかなぁ。みんなどうしてんだろ。

メジャーバージョンアップのたびに大幅な仕様変更があるから、結局その際には1からカスタマイズし直すことになるんだろうけど。うーん。

ちょっと前にニュース等で話題になった「ミクシィ、画像に認可制御なしの欠陥を改修できず、ヘルプで弁解」と同じ問題をOpenPNEも抱えている上に、手嶋屋の反応見る限りオフィシャルに何らかの対策が講じられることも無さそうので；なんとか自力で対策できないかということで考えてみた。

まず考えたのは、OpenPNEがインストールされてるディレクトリを丸ごとBasic認証で保護しちゃう方法。とりあえずお手軽に直リンは防げるけど、2回認証しなくちゃならないしユーザーがどんどん増えるようなサイトでは、Basic認証用のIDとパスワードをどうやって追加していけばいいか想像付かなかったんでボツ。

で、友人のプライバシーを保護するのと勉強と自己満足をかねて/public_html/img.php に手を入れてみることに。
ベースにしたのは、バージョン2.2.10のimg.php。

スクリプトの先頭のほうに

session_cache_limiter(‘private_no_expire’);

を追記。
61行目〜66行目の

$img->set_requests($_GET);

$img->generate_img() or exit(1);
while (@ob_end_clean());

$img->output_img() or exit(2);

の部分を、以下のように書き換え。

//保護する画像の指定
$secure_img = array (
“/^d_/”,
“/^t_/”,
“/^tw_/”,
“/^m_/”
);

$img->set_requests($_GET);

$securefound = ”;
foreach ($secure_img as $value) {
if (preg_match( $value, $img->requests['filename'])) {
$securefound = true;
}
}

if ($securefound) {
//ログインチェック
require_once ‘OpenPNE/Auth.php’;
$auth = new OpenPNE_Auth();
$pc_login = $auth->auth();

//携帯からのアクセス？
require_once ‘util/ktai.php’;
$ktai_login = isKtaiUserAgent();
}

if ($pc_login || $ktai_login || !$securefound) {
$img->generate_img() or exit(1);
while (@ob_end_clean());
$img->output_img() or exit(2);
}

前回のmod-davの改造といい、ハズカシすぎる（泣）。もっとスマートにやる方法があるんだろうなぁ…。ちゃんと勉強しなきゃないけませんな。でも現状のものに後付けで対策するとどーしても不格好になると思う（言い訳）。

しょーもない改造だけど、ログインしてない状態では「日記の画像、コミュニティのトピック内画像、プロフィールの画像」について、URL直打ちで表示されなくなった。全部を認証チェックしてると負荷が大きそうだったんで一部だけを認証チェックするようにしたんだけど、それでも認証が必要な画像を呼び出すと毎回DBから画像を生成するようになっちゃった（なんで？オレの頭じゃ理由がわからん）おかげで体感できるほど重くなった。これを回避するためにsession_cache_limiter(‘private_no_expire’);を使った。でもこれだとWin_IEのキャッシュが更新されないままになってそうでちょっと心配。あと、携帯版の認証状態をどうやって判定したらいいか解らなくて携帯からアクセスした場合は全部スルーしてます。UserAgent偽装されたらアウトかと思ったけど偽装しただけだと表示されなかった。抜け道ありそうだけどある程度の抑止力にはなったと信じたい。

とりあえず期待する動作をするようにはなったみたいなので、どの程度パフォーマンスに影響が出たのか調べてみることに。
ウチの自宅サバで動かしてるSNSの場合ユーザー数が10人、Myホームページでimg.phpを呼び出している部分がおよそ50箇所あるので、

ab -n50 -c10 http://www.hoge.jp/img.php?filename=xxx.xxx

とこんな感じで ab 使ってベンチマークを取ってみた。
※今までphpスクリプトのベンチマークなんか取ったことないんで、これで性能評価になってるのかどうかこれっぽっちも自信が無いです。まぁ参考程度に。

改造前のimg.php

Requests per second: 13.86 [#/sec] (mean)

改造後のimg.php（認証なしの画像を参照）

Requests per second: 13.52 [#/sec] (mean)

改造後のimg.php（認証ありの画像を参照）

Requests per second: 7.66 [#/sec] (mean)

結果を信じるなら、この改造で認証ありの画像を参照した場合のパフォーマンス低下が凄まじい。
動かしてるサーバーが玄箱なので、そもそもの処理能力低いんだろうけど、体感的には重すぎて話にならなくなったって感じでもないかな。ユーザー数が1000人を越えてるようなサイトの場合にはこれじゃ使い物にならないかもしれないけど、友人だけが参加者みたいな超小規模SNSを運営してて、外部から画像に直リンされるのがどーしてもヤダっていう人、あるいはBIZモードで社内SNSとかにして使ってる場合はやってみる価値がありそう。

まぁどっちにしても、SNSの参加者が画像ファイルそのものを別の場所に転載することは防げないんで、こういう対策しても根本的な解決にはならねーなぁ。結局、晒されたら困るような画像は掲載しないに限りますな。