フレームワークを便利にするプラグイン！

ユーザ登録を行うモジュール内でSSLを利用する例

　例として、ユーザ登録を行うモジュール（registerモジュール）内でSSLを利用するシーンを設定することにします。

1. まず個人情報保護方針に同意してもらう（privacyPolicyAction）
2. フォームに個人情報を入力してもらう（registerFormAction）※要SSL
3. 内容を確認してもらう（registerConfirmAction）※要SSL
4. 登録完了のお知らせ（registerFinished）※通常へ戻す

　この場合、まずregistereモジュール内で初期値をSSL必須としておきたいと思います。これは、今後アクションの仕様が変更になったり追加されたりする場合を想定し、漏れをなくすためです。

　次に最初の個人情報保護方針のページは、単体ではSSLの必要はないので、ここではfalseとし、SSL通信でなくても許可することにします。次に入力・同意してもらうページですが、ここは「all」で必須と宣言しているので必要ありません。

　最後に完了ページでSSLを終えて通常のHTTPに戻しておきます。常にSSLを有効にし続けるとトラフィックが無駄にかかりますし、意味なくSSLにしておく理由はないためです。以上の設定を具体的に示すと、リスト4のようになります。

　非常にシンプルになりました！ これで、アクションロジックに頑張ってSSLの判定処理を書かずにすむようになりました。

　前述したように、SSLの利用は基本ながらも、筆者も毎回記述するのはとても面倒に感じていたので、このプラグインを使えばとても簡単に利用できるようになり、大変重宝しています。

まとめ

　今回は「プラグインとは何か」から実際にsymfonyのプラグインの導入・設定・利用までを駆け足で追ってみましたが、いかがでしたでしょうか。

　symfonyでは設定関連をYAMLで管理しており、基本的なポリシーとして、設定ファイルで足りるものは設定ファイルに記述し、実際のロジックを最大限に削減しようとしているのが見て取ることができます。

　今回紹介したSsLRequirementプラグインもその1つで、symfonyのデフォルトのフィルタ機構を利用したものになっています。実際のロジックを廃し、プラグイン化することでロジックがシンプルになり、再利用を促進しています。再利用の最大のメリットである、コードを書かずに効率を最大化することが実践された1つの例と言えるでしょう。

　さて次回は、全5回にわたる今回の記事について振り返ってみたいと思います。