1

ユーザー資格情報を MySQL データベースに保存するための最良の方法は何でしょうか。データではなく構造を意味します（ハッシュとクリーンテキスト）。

私たちが得たサイトがあります

Root Admin (1)

Client Admin (1) 
Client Sub-Admins (N)

Employer Admin (N)
Employer Sub-Admins (N)

上記のユーザーはバックエンド ページでログインします

Users (N)

ユーザーはサイトのフロントエンドでログインします

N - 無制限を意味します

私の質問は、すべての管理者を同じテーブルに配置する必要があると思いますか? ただし、雇用主はクライアント管理者ほど信頼されていません。

管理者を別のテーブルに配置した場合、PHP で認証を行うにはどうすればよいですか? 両方のテーブルからデータを取得して配列にマージし、ユーザーが存在する場合は配列を調べますか?

4

4 に答える 4

3

user_idルート/クライアント管理者が1人だけの場合は、SQLインジェクションなどで変更するのが難しい構成ファイルに、値を個別に保存することをお勧めします。それ以外の場合、次のスキームでは、必要な数のグループにできるだけ多くのユーザーを割り当てるためのかなりの柔軟性が得られるはずです。

TABLE users
  user_id INT PK AUTO_INCREMENT
  user_name VARCHAR
  user_password VARCHAR
  ...

TABLE groups
  group_id INT PK AUTO_INCREMENT
  group_name VARCHAR
  [possible permissions declarations, 
    or create a similar group_perms table]
  ...

TABLE user_group_map
  user_id INT PK
  group_id INT PK
于 2012-11-01T17:37:37.773 に答える
1

これを行う 1 つの方法は、認証/ユーザー プロファイル データを可能なロールの配列から分離することです。したがって、ロールをユーザーに割り当てます。地獄、あなたの役割にコンテキストを割り当ててください。私の見方では、ユーザーとロールの間に 1 対多の関係があり、ロールにはコンテキスト (雇用主の管理者、クライアントの管理者、一般管理者...) が割り当てられます。

于 2012-10-29T18:16:05.413 に答える
0

信頼度に基づいてユーザーを分離するためだけに、複数のテーブルを使用することはありません。質問とコメントを読んだ後、ルート管理者、クライアント管理者、雇用者管理者、および通常のユーザー用に個別のテーブルを作成する必要があります。これは、グループごとに信頼レベルが異なるためです。テーブルが2つしかない場合でも、コーディングを開始すると、実装/メンテナンスが非常に醜くなる可能性があります...

ただし、個別のテーブルを使用することを非常に決意しているようですが、そうすることを選択した場合、これを「隠す」ことができる手法があります。たとえば、これらのテーブルをマージするビューを作成する、DAO で SQL ユニオンを使用する、またはそれぞれを読み取るなどです。繰り返しますが、アプリケーションを構築するときに、この設計で問題が発生する可能性が高くなります。

単一のテーブルを使用して、それらの間に多対多の関係があるusersという概念を導入したいと思います。rolesユーザーの作成時に、各ユーザーをデフォルトのロール (たとえば、ユーザーroot-adminには root-admin のロールがあるなど) と、それらに適合すると思われる他のロール (たとえば、ユーザーcleint-adminには追加のロールがあります) を関連付けます。 client-sub-admin の役割など) 要件に基づいて、ユーザーに直接関係しない役割が存在する可能性があります。ゲスト、メンバーなど

また、ロールとのオプションの多対多の関係を持つアプリケーションの概念を紹介し、contexts最初にロールroot-adminをアプリケーション コンテキストに関連付けます。これは、制限がないことを意味します。ビジネス要件に基づいて、追加のコンテキストが作成されます (たとえば、ロールEmployer-adminは、コンテキストHire-employeesの一部であるなど)。

承認時に、セキュリティ マネージャー コンポーネントは、必要に応じて追加のロジックを含めて (たとえば、ユーザーが無効になっている)、ユーザーとそれに関連付けられたロール/コンテキストに基づいてアクセスを許可/拒否できます。

次の懸念は、他のユーザーには適用されない特定のユーザーの追加データがあることでした。これを解決するためprofilesに、ユーザー テーブルとのオプションの 1 対 1 の関係を持つテーブルを導入します (すべてのユーザーがプロファイルを持っているわけではありません。たとえば、ユーザーroot-adminは持っていません)。

スキーマ (ドラフト):

 __________________                    __________________
|USERS             |                  |ROLES             |
|==================|                  |==================|
|id                |                  |id                |
|username          |  1..*      1..*  |name              |
|password          |  --------------  |description       |
|failedattempts    |                  |...               |
|disabled          |                  |                  |
|...               |                  |                  |
|__________________|                  |__________________|

        | 1                                   | 0..*
        |                                     |
        |                                     |
        |                                     |
        | 0..1                                | 0..*
 __________________                    __________________
|PROFILES          |                  |CONTEXTS          |
|==================|                  |==================|
|id                |                  |id                |
|firstname         |                  |name              |
|lastname          |                  |description       |
|email             |                  |...               |
|dob               |                  |                  |
|...               |                  |                  |
|__________________|                  |__________________|
于 2012-11-02T15:01:05.013 に答える
0

この投稿で、ユーザーとグループのパーミッション システムについて説明しました (タイトルは無視してください -- 元の質問の言葉遣いが不十分でした): Applying column permissions for a table over a trigger

于 2012-11-04T02:25:39.873 に答える