■

昨日の書き込みの続編です。

jflute様のコメント

• USER
• USER_ROLE *関連テーブル
• ROLE
• ROLE_FUNCTION *関連テーブル
• FUNCTION

という５つのテーブルを作って、
「ロール」と「機能」をn:nの関係にします。
「機能」には「とある画面のXxx機能」が格納されます。
但し、ここの粒度はシステムによりけりで、
単純に画面だけでユニークな場合もあれば、細かく画面とボタン単位
な場合もあります。もっと単純に画面とか関係なく
「Insert/Update/Delete/その他」もありえるでしょう。
粒度が荒い細かいのいずれにせよ、この形でほとんどまかなっています。

とある画面の「読み取り権限、書き込み権限」を表現する時は、
ROLE_FUNCTIONに「読み取り・書き込みフラグ」を立てて、
「機能」には単純に画面を入れるやり方と、
「機能」に「とある画面の読み取り」と「とある画面の書き込み」を
入れるやり方と二通りあります。
(つまりは「機能」をどういった単にするかがポイント)』

もう少し教えていただけませんでしょうか？

早速設計してみましたが、下記のような単純な設計になりました。
読み取り権限、書き込み権限系は、

「機能」に「とある画面の読み取り」と「とある画面の書き込み」を入れるやり方

を取り入れようとしています。

■Userテーブル
id
:
省略

■UserRole
user_id
role_id
version

■Roleテーブル
id
role_name
version

■RoleFunction(関連テーブル）
role_id
function_id

■Functionテーブル
id
function_name
version

これで、一応権限系制御はできるかと思いますが、
具体的にイメージした時に以下のようになるかと思います。

前提：horohoro1でログイン。horohoro1は一般ユーザなのでユーザ情報更新はできない。
1.（例えば）horohoro1はユーザ情報更新画面のユーザ情報更新をするボタンを押す
2.システムはHttpSessionに存在するhorohoro1のロール群を見に行き、そのロール群が
　持っているファンクション名をひとつずつ確認する
3.システムはファンクション名を確認した結果「ユーザ情報更新」と名前のファンクション名
　が存在しないので、更新処理はできませんというエラーを出す

※または、ユーザ情報更新画面へのリンクは2と3を行った結果、表示させないようにすることでも実現できる。

■質問１
テーブルのカラムが非常に単純なものですが、何か足りないものはありますでしょうか？

■質問２
制御の処理の流れは、上記1〜3のようなイメージで、jflute様が行っているやり方と相違ないでしょうか？

お手数ですが、教えていただけますと嬉しいです。