0

ユーザー名/パスワードを持つプログラムがあります。各ユーザーには「セキュリティ レベル」があり、現時点では (まだアプリの初期段階にあるため)、「管理者」と「アソシエイト」の 2 つのオプションがあります。ソフトウェア レベルでは、アソシエイト レベルのアカウントにはハードコーディングされた制限があり、管理者レベルのアカウントには制限がありません。

しかし、これ以上の多様性が必要です。アプリ内の 1 つの画面にのみアクセスする必要があるユーザーもいれば、複数の画面にアクセスする必要があるユーザーもいます。さまざまなオプションがあります。これらは私が考えた解決策です：

  1. ハードコーディングされた制限による複数のセキュリティ レベル。- これが最も簡単だと思いますが、セキュリティ レベルのリストが場当たり的すぎるように見えるため、良いアイデアではないと思います。IE の場合、「このユーザーは画面 x、y、z のみを表示する必要があるが、それ以外は何も表示しない」というニーズが与えられるため、新しいセキュリティ レベルをコーディングし、それらの制限をハードコーディングするだけです。さらに悪いことに、ハードコーディングされた各セキュリティ レベルを説明する必要があります。そうしないと、レベルを変更しようとしている管理者が、自分が何に変更しようとしているかわからなくなります。
  2. 各カスタム アカウントが表示できる画面を管理者が選択できる、画面付きの「カスタム」セキュリティ レベル。- これは私の理想的なアプローチですが、これをデータベース レベルで概念化しようとしています。

＃2については、次のように2つのテーブルを作成する必要があります。

Table: custom_user_permission
   | user_id | screen_id |
 --|---------|-----------|
 1 |      5  |        1  |
 2 |      5  |        2  |
 3 |      5  |        3  |
 4 |     12  |        1  |
 5 |      4  |        2  |

そして別：

 Table: screen:

   | id (PK) | screen_name |
 --|---------|------__-----|
 1 |      1  |   Screen x  |
 2 |      2  |   Screen y  |
 3 |      3  |   Screen z  |

これがソフトウェア レベルでどのように解釈されるかはわかりませんが、おそらく 2 番目の表の代わりに、screen_idソフトウェア レベルでどの画面に適用されるかを定義する方がよいでしょう。これにより、データベース上で「screen_id」が任意の整数になり、読み取りが困難になります。

  1. 1 と 2 の混合- おそらく、管理者が独自のセキュリティ レベル プロファイルを作成できるようにします。しかし、複雑さという点では、どちらも最悪です。:)

誰でもアドバイスがありますか？私の考えでは、これはかなり一般的な問題ですよね？

4

1 に答える 1