フレームワークの機能要件から見る CakePHP
すでに CakePHP 以外の実績あるフレームワークも数多く存在します。以下は CakePHP 入門者や、他のフレームワークから CakePHP へ移行を検討している方に有益かと思われます。
MVC パターン
CakePHP では URL からコントローラとアクションを決定します。ドキュメントルートの直下にフロントコントローラ( index.php )がある場合、以下は…
http://sample.tld/users/registusers というコントローラの regist というアクションにマッピングされます。具体的なサンプルは次のようになります。
class UsersContorller extends AppController { function regist() { // コントローラの処理を書く } }
別のアクションを追加するには regist() と同じようにメソッドを追加します。
セキュリティ
CakePHP では、シンプルでありながら有用なセキュリティ対策があります。フレームワークを選択する際、気になるのは post データの改ざんを防止できるか?という点です。 CakePHP では2つのアプローチと1つの鉄則があります。
- post 以外のリクエストを拒否する
- 正規のトークンを含まないリクエストを拒否する( Struts 風)
後者は post データの改ざんに加え、送信ボタンの2度押しをブロックする作用もあります。しかし、これで post データの改ざんを完璧に防げるわけではありません。たとえば form の hidden 要素を input に変更したり、リクエストをキャプチャしてデータを書き換えたりする手段は容易に見つけることができます。 post データは永続化する直前でバリデータに通す必要があります。これが鉄則ですが、 CakePHP ではデータを永続化する際にバリデータが自動的に働きますので、検証ルールの不備がなければあまり意識しなくても済むかもしれません。
サニタイジング
CakePHP の提供するサニタイザには HTML や SQL などのメタ文字をエスケープするという基本的なメソッドが提供されています。しかし、おそらくもっとも頻繁に利用されるであろう HTML ヘルパーでは、データを出力する際、自動的に HTML のメタ文字をエスケープしますので、ごく単純なメールフォームなどの Web アプリケーションでは、サニタイズを意識することが無いかも知れません。
また、入力と出力のデータを徹底的に浄化したい場合、リクエストからコントローラ、コントローラからビューへと遷移する2カ所でデータを掌握できるタイミングがあります。そこでは、たとえば ascii コード中の不可視バイトを削除することができます。
フィルタチェイン・アクションチェイン
CakePHP ではフィルタチェインとアクションチェインを直接的に設定する場所はありません。フィルタチェインは Controller::beforeFilter() を拡張して記述します。アクションチェインはアクション内で Controller::requestAction() を呼び出すことで実現します。 Controller というのはコントローラの基底クラスです。
ソースの自動生成
CakePHP には bake.php というソースジェネレータがあります。 bake.php ではモデル、コントローラ、ビューの3つを生成可能です。 bake.php を利用すると scaffold と同等のソースを生成します。
なお、 bake.php で生成されるソースは、たとえば、よくあるマスタ管理の新規登録や編集に際して、データ入力画面と登録完了画面との間に確認画面を挟みません。これは日本ではあまり好まれないスタイルかも知れませんが、当然、自分でロジックを記述すれば、確認画面を挟むことは簡単です。
