web-dev-qa-db-ja.com

ユーザーの権限をデータベースに保持する方法は？

データベースでユーザーの権限を追跡するために受け入れられている方法は何ですか？ユーザーが特権の支払いを行えるWebアプリがあるとします。簡単な類推を使用するには、Githubのユーザーを想像してみてください（有料のメンバーはプライベートリポジトリなどを持つことができます）。

account_type: String

もう1つの方法は、一連の権限を保持することです。

permissions: [String]

どちらが好ましいですか？

databasepermissionsusers
3
db2791

お金が関係していて、マーケティングチームが将来何を夢見るかを誰が知っているなら、権限と役割を使います。

権限は、新しいプライベートリポジトリの作成など、システム内の単一のアクションです。ロールは権限のコレクションです。ユーザーには、任意の数のロールを割り当てることができます。開始日と終了日を入力して、ユーザーに一定期間ロールへのアクセス権を付与できるようにします。

6
Greg Burghardt

私はそれがさまざまな方法で行われるのを見てきました。 「無料アカウント」と「有料アカウント」の間の単純な切り替えである場合は、単一の0/1整数フィールドまたは列挙型で実行できると思いますが、多数の異なる権限がある場合は、おそらくビットストリングを使用する必要があります。個々のビットは、特定の権限またはアカウント設定を表します。

1
Govind Parmar

データ構造にはさまざまな方法があります。

変数

can_edit = true
is_admin = true

Key-Valueペアテーブル内のKey-Valueペア、またはmongoのようなKey-Valueストア

can_edit : true
is_admin : true

キーと値のペアのハッシュ。ルビー

{
can_edit => true
is_admin => true
}

さまざまなtrue/falseフィールドを持つ「ユーザー」用のデータベーステーブル

users
can_edit BOOLEAN
is_admin BOOLEAN

ユーザーとロールのデータベーステーブル、およびアクセス許可の結合テーブルとして機能する別のデータベーステーブル。つまり、user_idとrole_idの列が含まれます。

mysql> describe users;
+----------+-----------+------+-----+---------+----------------+
| Field    | Type      | Null | Key | Default | Extra          |
+----------+-----------+------+-----+---------+----------------+
| id       | int(11)   | NO   | PRI | NULL    | auto_increment |
| user_id  | int(11)   | NO   |     | NULL    |                |
| role_id  | int(11)   | NO   |     | NULL    |                |
+----------+-----------+------+-----+---------+----------------+

上記の例ではcan_editおよびis_adminは、rolesテーブルに保存されたロールであり、各ロール行ごとに1行が一意のIDを持ち、そのロールを持つユーザーのuser_idとともに上記の権限テーブルで参照されます。

1
Michael Durrant

あなたが言及する配列ロジックは、必須の言語ソリューションであり、データベースへの格納にはあまり適していません。

リレーショナルデータベースは、配列の概念に多少似ていますが同じではないセットロジックを使用します。拡張可能な配列のようなセット/テーブルについて考えます。

問題の最も一般的なデータベース設計（さまざまなバリエーションがある）には、データ要件の正規化の結果である3つのテーブルが含まれます。

a）ユーザー、id_userやlogin_userなどの基本フィールドと必要なフィールド（first_name、last_nameなど）

データの例：id_user login_user 1 admin 2 db2791 3 bruno

b）アクセス許可。id_permissionやname_permissionなどの基本的なフィールドの例データの例：

id_permission name_permission 1リポジトリを作成2リポジトリでコミット

c）ユーザー-アクセス許可関係テーブル。基本フィールドは外部キーid_userおよびid_permissionです。次に、権限のレベルが異なる場合はフラグを立てます。 can_read、can_write、代わりに独立したアクセス許可

データの例：id_user id_permission 1 1 1 2 2 2

関係にデータがないことは、許可がないことを意味します。明示的な権限の削除を許可するために、許可/拒否フラグを追加することができます。

これを拡張するもう1つの一般的なパターンは、Resourcesテーブル（またはセキュリティ保護可能なリソース）を追加して、ユーザー-権限-リソースへの関係を変更することです

0
Bruno Guardia