PHPでのフォーム処理を見直したりする

数年前とか数年以上前とかに作った、申し込みフォームをリニューアルすることになったので、処理を見直しています。

フォームは、入力部品を作成する時点で、PHPの連想配列にすべてまとめてしまいます。

<label for="cname">名前</label><input type="text" id="cname" name="sheet[name]" value="$sheet[name]">
<label for="cyomi">フリガナ</label><input type="text" id="cyomi" name="sheet[yomi]" value="$sheet[yomi]>

みたいな感じで、$sheetにフォーム内の入力項目を全部まとめてしまいます。
POSTデータを受け取ったスクリプトでは、$sheet変数の中身にだけ気をつければいいので、この方法は楽です。

さて、今回はオーダーメイドのフォームを作るのに飽きてきたので、汎用の入力検査処理をコーディングしてしまおうと考えています。
汎用化は、たしかにオーダーメイドに比べるとエラーに弱かったりバグが発生したりする可能性が大です。でも、それほど多種多様なケースに対応しなければならない状態というのは、いまのところ経験的に存在しません。
ということで、えいやっと作り始めたのはいいんですが。。。

ああ。とても面倒です。セキュリティ面の事も考慮すると、どうしても作業もデータも分散させざるをえません。
入力項目の検査は、検査対象となる入力項目のラベル、値への参照用コード、検査項目一覧情報をXMLに記述して、外部からはアクセスできない場所に置きました。フォームがPOSTされた後の処理は、これでOKです。
今度は、フォームの入力中に動的に行われる検査をコーディングしなければなりません。
フォームが正しく動くようになったら、人的ミスを最小限にするために、フォームの設定を記述したXMLから、ディレクトリを作成し、フォームの雛形を生成して、フォームの動作に必要なファイル群を正しい位置に配置してくれるようなヘルパ・スクリプトを用意しなければなりません。
もう、この時点でオーダーメイド・フォームを作成する作業の５割増しを軽くオーバーしています。

いや、選択を間違えたかもしれませんね。
いざとなったら、最後のスクリプトは無かったことにするかも。。。納期まであと1週間だし。。。

LogWatchの監視項目を減らす方法

毎日、毎日、３０台以上のマシンからLogWatchがシステムログのサマリーを送ってくれているわけですが、とある開発用サーバーがFTPの転送ログをこれまた毎日数十メガバイト分も送りつけて来ます。

ロギング自体をストップする権限は無いので、LogWatchからFTPの転送ログだけを除外することにしました。
マシンのOSは、CentOS-5.5です。

ところが、/etc/logwatch/conf/logwatch.confの中身は空です。
本体は/usr/share/logwatch/default.conf/logwatch.confにあって、こちらは変更したくありませんね。

ということで、ググって見つけました。

Stop logwatch reporting on a particular service on CentOS

サービス名の前にマイナス記号を入れることで、設定をオーバーライドできるようです。
/etc/logwatch/conf/override.conf:
Service = "-ftpd-xferlog"
---
とすることにしました。

Resinの実行アカウント

Resinサーバーをdebパッケージでインストールすると、rootアカウントで実行するように設定されてしまいます。この状態だと、サーバー上で動作させるアプリケーションもrootとして動作してしまうため、ミスの内容によってはシステムを破壊してしまうこともあります。

そこで、www-dataという制限ユーザーでアプリケーションを実行させるため、ちょっと調整を行います。
まず、/etc/resin/resin.xmlを修正します。

        184: <user-name>www-data</user-name>
        185: <group-name>www-data</group-name>
        186:  -->

という部分を探してください。コメントアウトされていますので、186行目のコメント閉じマークを移動させるなりして、ユーザー名とグループ名の指定を有効にします。

続いて、

/var/www/webapps
/var/www/resin-data
/var/www/log
/var/www/doc

以上４つのディレクトリと、その中身のオーナーをwww-dataに再設定します。

これで準備が完了しました。Resinサーバーを起動してみてください。また、問題が起きていないかログを確認する事も忘れないようにしましょう。

Resin-4.0の簡易評価

BLOGスペースを作ったことをすっかり忘れてました。。。

気を取り直して、Resinの評価です。
ResinというのはJ2EEサーバーなのですが、あまり日本では話を聞きません。
じゃあ、そんなマイナーなものをどうして、という話ですが、他のJ2EEサーバーと比較してResinが有用だと思われるケースがあるからです。
ResinにはQuercusというサーブレットが付属していて、PHPスクリプトを実行することができる。というのが利点です。

Debian系のLinuxにResin(-pro)をインストールすると、デフォルトのWEBサーバー用ディレクトリとして、/var/www/webapps/ROOTが作成されます。
でもって、ここにPHPファイルを置くと、そのまま実行できてしまうわけです。

さらに言うと、このResin上で動作するPHPはエンジン部分が拡張されていて、Javaのクラスモジュールなんかをimportできてしまいます。便利ですね。
ライブラリとかフレームワークの概念が無いプログラマに対抗するには、PHPスクリプトで作ったモジュールをWARファイルにまとめてデプロイするというような技も使えます。でも、WARファイルがZIPファイルであることを教えてはいけません。それこそ元の木阿弥です。w

既存のJ2EEサーバー上でPHPスクリプトを実行させたい場合は、Quercusモジュールを対象のJ2EEサーバーにデプロイしてあげれば、PHPの実行環境ができあがります。（web.xmlとかに設定を行う必要はあります）

Resinサーバーのアドバンテージは、PHPスクリプトをJavaにコンパイルして高速動作してくれることです。他のJ2EEサーバーでQuercusを利用する場合このアドバンテージは無くなりますが、J2EEサーバー上のライブラリを利用可能なPHPプログラムの開発という時点で何となく特した気分になれるかもしれませんね。