この特集のトップページへ
Chapter 6:ビジネスロジックの設計

head1.gif 6.7 雑多な処理

 以上で,顧客の管理処理,製品の管理処理,伝票の処理,請求書の処理と,必要なメソッドはすべて揃った。しかし,あと2つ,メソッドを用意しておきたい。それは,ロールの判定処理と承認不要な伝票の限度額を返すメソッドである。

head2.gif 6.7.1 ロールの判定処理
 いままで実装してきたメソッドは,ロールによって利用できる機能を制限したり,特定のロールに属さないユーザーから呼び出されたときにはエラーを返すなどの処理をすることで,アプリケーションが適切なセキュリティを保つようにしてきた。

 しかし,ユーザーがアプリケーションを操作することを考えると,たとえばアプリケーション内の特定の機能を使おうとしたときに,「その機能を使う権限はありません」といったメッセージを表示するよりも,そもそも使えない機能は表示しないようにしたり,メニューやボタンであれば灰色表示(Disable表示)にしたりして,機能そのものを選択できないようにしたほうが使いやすいだろう。

 そこで,プレゼンテーション層から,ユーザーがどのロールに属しているのかを返すメソッドをビジネスロジックに実装しておく。どのような名前のビジネスロジックに実装してもよいが,ここでは,Business.Utilityという新しいコンポーネントを導入し,そのなかにメソッドを実装することにする。

 そのためにまず,BusinessプロジェクトにUtilityというクラスモジュールを追加する。クラスモジュールを追加するには,Visual Basicの[プロジェクト]メニューから[クラスモジュールの追加]を選択すればよい。そして,追加したUtilityクラスモジュールのトランザクションの状態を「新しく必要」に設定するため,MTSTransactionModeプロパティを[RequiresNewTransaction]に変更する(Fig.6-104)。

Fig.6-104 BusinessプロジェクトのUtilityクラスモジュールのMTSTransactionModeプロパティ
fig6_104

 次に,ロールを判定するためのメソッドを実装する。ロールの判定はObjectContextオブジェクトのIsCallerInRoleメソッドを使って調べればよいだけである。このサンプルでは,Table 6-3にも示したように,SalesSalesManagerProductsAccountingSalesAdminProductsAdminAccountingAdminAllAdminという8種類のロールを扱う。まず,これらのロールに対応する列挙型をList 6-198のように用意する。

 Business.Utilityコンポーネントに実装するロールを判定するメソッドでは,メソッドを呼び出したユーザーがどのロールに属するのかをList 6-198に示したUSERROLE列挙型の組み合わせとして返すことにする。たとえば,Salesロールに属しているならばROLE_SALESを,Productsロールに属しているならばROLE_PRODUCTSを,それぞれ値として返すようにする。もちろん,複数のロールに属していることもあるが,その場合には和をとって返す。たとえば,SalesAdminSalesManagerという2つのロールに属するユーザーであれば,ROLE_SALES Or ROLE_SALESMANAGER(値としては1 Or 2 = 3)いう値を返すものとする。

 このような機能を備えたメソッドを,実際にGetUserInRoleという名前でBusiness.Utililtyコンポーネントに実装する(List 6-199)。List 6-199GetUserInRoleメソッドの内部は,ObjectContextオブジェクトのIsCallerInRoleメソッドを使ってロールを判定するIf文の羅列でしかない。


One Point!  List 6-199では,SetCompleteメソッドやSetAbortメソッドを使ってトランザクションのコミットやアボートを処理しているものの,データベースを操作しているわけではない。そのため,実際にはこのようなトランザクションの決定処理は不要である。また,そもそもトランザクション範囲内で実行させる必要性もない。すなわち,List 6-199の43行目にあるSetCompleteメソッドの呼び出しや51行目のSetAbortメソッドの呼び出しを削除し,UtilityクラスモジュールのMTSTransactionModeプロパティを[NoAnMTSObject](MTSオブジェクトではなく,「トランザクションは不要」という設定)に変更してしまっても一向にかまわない。

One Point!  ロールの判定処理をビジネスロジックに実装すると,場合によっては,それがセキュリティホールになる可能性もあるので注意してほしい。List 6-199のようにUSERROLE列挙型のフラグとして返す場合には,さして問題はない。しかし,属するロールを文字列などで返すように実装する場合は,サーバー側にどのようなロールが存在するのかを外部にさらすことになる。外部にさらしたところで即座にどうこうなるものではないが,クラッカーの興味の対象となるのは事実であろう。
prevpg.gif Chapter 6 90/92 nextpg.gif