3

小さなユーザーシステムを作るつもりですが、質問があります。

  1. 登録テーブル(mysql)を作成する場合、暗号化せずにパスワードとユーザー名をデータベースに保存するだけで何が問題になりますか?

  2. 管理者部分の作り方を考えています。データベースの列をチェックして、ユーザーが管理者であるかどうかを確認する必要がありますか?trueの場合、管理ページが表示されます。 

  3. 管理者権限については、ユーザーの削除、ユーザーの承認、ユーザーの移動の3つの権限があるとします。いくつかのシナリオでは、承認、削除、すべて、または任意の組み合わせの機能のみを提供したい場合があります。どうすればこれを作ることができますか?パワーごとに列を作成し、スクリプトに各列をチェックさせることを考えていました。追加されるパワーが20以上あると仮定しましょう。

  4. 人々がグループを作成してグループの管理者になることができるWebサイトがあり、これらの管理者がグループ内の人々にさまざまな管理権限の組み合わせを与えることができる場合(たとえば、ZackはMountainというグループを作成し、1人のメンバーに新しい承認機能を付与しますメンバーをグループ化し、2番目のメンバーにメンバーを削除する機能を付与し、3番目のメンバーに削除と承認の機能を割り当てます。MySQLでこれをどのように構成しますか?管理しているグループとその機能を示す列を使用する必要があります持っていますか?例:削除、承認、GroupMemberOf、GroupAdminOf、および使用チェック。

アイデアはありますが、もっと洗練された方法を学びたいです。

これまでの回答に感謝しますが、私は本当に構造に関するアイデアを探しています(質問2-4)。質問を解決するのを手伝ってくれるかどうか教えてください。

4

8 に答える 8

5
  1. ユーザーごとに一意のソルトを使用してユーザー パスワードをハッシュします。これにより、部外者がデータベースにアクセスできる場合、パスワードを解読できず、ソルトがレインボー テーブル攻撃を緩和します。

2 - 4. アクセス レベル (1: メンバー、2: モデレーター (承認)、3: 管理者) 用のテーブルを使用し、次のような多対多接続を格納するユーザー権限用にさらに別のテーブルを使用します。

id (auto_increment)|usr_id|role_id|group_id
-------------------------------------------
1                  |1     |3      |-1
2                  |2     |2      |1
3                  |2     |3      |2
4                  |3     |1      |2

あなたの場合、ユーザー 1 はサイト全体の管理者、ユーザー 2 はグループ 3 の管理者、グループ 2 のモデレーター、ユーザー 3 はグループ 2 のメンバーです。

[編集:]

さまざまな役割の権限を制限することに関するいくつかの考え: 設定によっては、ページごとにいくつかの役割の強制を使用する必要があります。たとえば、MVC フレームワークでは、基本コントローラーを拡張して、(役割) 承認機能を必要とするようにします。そうしないと、例外をスローする必要があります。ユーザーのログインを必要としないメソッド (ページ) では、ダミーの承認を使用できます。

したがって、認可クラスは次のようになります

class Authorization
{
    public $authorized = false;

    public function dummy()
    {
        $this->authorized = true;
    }

    public function member($usr_id, $group_id = null)
    {
        $sql = "SELECT usr_id FROM usr_roles WHERE usr_id = " . $usr_id . ($group_id !== null) ? " AND group_id " . $group_id : "";
        // count the results of $sql query
        // or some more stuff
        if ($results > 1)
        {
            $this->authorized = true;
        }
        else
        {
            $this->authorized = false;
        } 
    }

    // the other functions
}

新しい基本コントローラー クラスは次のようになります。

class BaseController extends Controller
{
    protected $authorization;
    public function __construct()
    {
        $this->authorization = new Authorization();
    }

    public function render()
    {
        if ($this->authorization->authorized === true)
        {
            parent::render
        }
        else
        {
            // redirect to not authorized page 
        }
    }
}

最後に、コントローラーは次のようになります。

class IndexController extends BaseController
{
    // some stuff, methods etc.

    // methods needs logged in user and user must be a member. 
    public function index()
    {
        $this->authorization->member($session_user->getId());
    }
}

[EDIT2:]

OOP に慣れていない場合は、次の操作を実行できます。

ロール テーブルのサンプル レイアウトを次に示します。

role_id|role_name
-----------------
1      |member
2      |moderator
3      |admin

次に、関数 authorize() を作成して、すべてのファイルに含めることができます。

// role_name = "member", "moderator", "admin"
function authorize($usr_id = null, $role_name = null, group_id = null)
{
    // test for user in group and role, return boolean

}

ファイルにこの関数を含め、次の操作を行います

if (authorize($usr_id, "moderator", 2)
{
    // show stuff, if user with $usr_id is moderator for group 2
}
else
{
    // do something else
}
// stuff for all 
于 2009-11-02T15:51:17.077 に答える
3
  1. 暗号化せずにパスワードを保存すると、誰かがデータベースを盗んだり、データベースへの読み取りアクセスを取得したりしたときに、顧客のすべてのパスワードが明らかになります。悲しいことに、ほとんどの人はサイト間でユーザー名とパスワードを再利用しているため、パスワードを保護しないことでユーザーを大いに嫌っています。(たぶん彼らはもっとよく知っているはずですが、ほとんどは知りません。)
于 2009-10-06T18:00:27.950 に答える
3

1)クリア テキストのパスワードを保存するということは、誰かがデータベースにアクセスしたとしても、パスワードを知ることができないということです。ソルトと暗号化パスワードに関する誇大宣伝は非常にばかげています。単純な方法は誰にとってもうまくいくでしょう。

$password = "Mypassword";
$salt = "a unique and constant string";
$password = md5($password.$salt);

md5() でパスワードを暗号md5();化した後は、パスワードを取り戻すことはできません。また、ソルトすることで、パスワードを見つける方法がなくなります。

パスワードが機能するかどうかを比較して確認したい場合は、以下のようにまったく同じ方法で入力を md5 するだけです。

$password = "check_this_password";
if(md5($password.$salt) === $originalPassword) 
{ 
    //same password
}

2)その質問は、グループを管理側とどのように統合したいかによって異なります。他の権限がまったく設定されていない場合は、アカウント レベルでデータベースに 1 つのフィールドを保存するだけで安全です。それ以外の場合は、次のポイントを使用して、管理者かどうかを確認してください。

3)アクセス許可システムを実装する最も簡単な方法は次のとおりです。他の方法もありますが、複雑にしないことが最善です。各グループのアクセス許可が必要な場合は、次のような追加の列を追加prm_group_idして、特定のグループのアクセス許可で各ユーザーを見つけることができます。とにかく、これがどのように機能するかです:

権限を保持するテーブルを作成する

prm_user_id  | prm_permission
   0         | Admin
   0         | Delete
   1         | Add

各行には、フラグまたは許可が保持されます。次に、SQL と PHP を少し使って、必要な権限を持っているかどうかを簡単に確認できます。

function hasPermission($permission, $userID)
{
  $permissions = array();

  $sql = "SELECT prm_permission FROM user_permissions WHERE prm_user_id = $userID";
  $query = mysql_query($sql);

  while($data = mysql_fetch_array($query))
  {
     $permissions[] = $data['prm_permission'];
  }

  //Check if they have a permission with this:
  if(in_array($permission, $permissions))
  {
     return true;
  }
return false;
}

これにより、アクセス許可の追加と削除が非常に簡単になり、アクセス許可があるかどうかを確認できます。唯一の欠点は、アクセス許可の管理が少しトリッキーになる可能性があることです。

于 2009-11-02T23:58:55.193 に答える
1

ポイント2〜4については、役割ベースのアクセス制御を確認することをお勧めします。

于 2009-11-03T11:46:30.760 に答える
0
  1. 明らかに、ハッシュ化して保存することをお勧めしますが、そうしないことにも利点があります。それは本当にあなたが必要とするものに帰着します。

2+。このための小さなSQLスキーマをここにまとめました

基本的に、必要なユーザー、グループ、および権限を別々のテーブルに保存します。次に、ユーザーをグループに関連付け、権限をグループ内のユーザーに関連付けます。人に「すべて」を与えるには、プログラミングロジック(PHPまたはMySQLに保存されたプロシージャ)が新しいユーザーにパーミッションテーブルで使用可能なすべてのパーミッションを与えることを確認するだけです。MySQLでこれを実現するには、次のようなクエリを実行できます。

INSERT INTO group_user_permissions
    SELECT `group_user`.`groupid`, `group_user`.`userid`, `permission`.`permbit`
        FROM permission, `group_user`
    WHERE `group_user`.`groupid` = 1
        AND `group_user`.`userid` = 1

これにより、指定されたgroupidとuserid(この場合はgroupid1とuserid1)のすべての可能なアクセス許可がgroup_user_permissionテーブルに挿入されます。

これで、権限を確認する必要がある場合はいつでも、group_user_permissionテーブルに対して非常に単純なクエリを実行して、そのグループ内のそのユーザーが、実行しようとしていることを実行する権限を持っているかどうかを確認できます。これは、permbitsの名前を変更したり、permbitsを追加したり、permbitsを削除したりする必要がある場合にテーブルを変更する必要がないため、最終的には柔軟性があります。

さらに、権限テーブルで文字列キーを使用しているため、これらの値をテキスト形式で使用して、読み取るときに意味があります(自動インクリメント番号を使用する場合とは異なります)。PHPチェックを次のように作成します。

if( $permbit === "approve" )

vs

if( $permbit === 1 )

幸運を!

于 2009-11-03T00:35:02.203 に答える
0

私はこれについてゲームに少し遅れていますが、CakePHP がどのように認証を行っているかを見てみたいかもしれません。(PHP を使用している場合は、CakePHP フレームワークを使用すると、コーディングしなくてもこの制御の一部が得られることに気付くかもしれません。)

ユーザー権限と Cakephp

また、エンティティに対するアクション (CRUD や管理など) のリストを保持しておくと便利であることがわかりました。そのため、通常のユーザー/パスワード テーブルとは別に、以下のようなフィールドを持つテーブルが必要になります。

PermID | 拒否または許可 | アクション | アクション | 実在物

次に、グループを PermId にマップする別のテーブルと、ユーザーとグループを (必要に応じて再帰的に) グループにマップする別のテーブルがあります (人々が既に話しているように)。

拒否または許可は、デフォルトでアクションを許可する場合 (通常はこれはおそらく最善の考えではありません)、または拒否する必要がある小さなグループがある場合に、使用を許可する ACL または使用を拒否する DACL を作成できることを意味します。より大きなものにアクセスします。通常、最初に、グループ/ユーザーのエンティティに対するアクションに明示的な拒否があったかどうかを確認します。

したがって、次のようなものがあるかもしれません:

PermID | タイプ | アクション | アクション | 実在物
-------+-------+---------+------------
  1 | 許可 | 読む | User_Entry
  2 | 許可 | 削除 | User_Entry
  3 | 許可 | 移動 | User_Entry
  4 | 許可 | 承認 | User_Entry
  5 | 許可 | 作成 | User_Entry

したがって、例として、管理者グループはエントリ 1 ~ 5 にマップされ、「通常のユーザー」グループは 1 と 5 のみにマップされる場合があります。(グループの場合は、必要に応じて「人」または「ユーザー」と読みます)。

ID | グループ | PermId
---+--------+-----
 1 | 管理者 | 1
 2 | 管理者 | 2
 3 | 管理者 | 3
 4 | 管理者 | 4
 5 | 管理者 | 5
 6 | ノーマル | 1
 7 | ノーマル | 5

新しいアクションまたはエンティティ (ディレクトリなど) がシステムで発生した場合、スキーマを変更する必要なくテーブルに適切なエントリを追加するだけなので、明らかにこれは簡単に拡張できます。たとえば、「すべて」のアクションを使用して、特定の除外に DACL を使用できます。これは、User_Entry の削除以外はすべて実行できるパワー ユーザーです。

PermID | タイプ | アクション | アクション | 実在物
-------+-------+---------+------------
  6 | 許可 | すべて | User_Entry
  7 | 拒否 | 削除 | User_Entry


ID | グループ | PermId
---+--------+-----
 8 | パワー | 6
 9 | パワー | 7

あなたの場合、システム管理者が持つ可能性のある UserEntry だけでなく、エンティティにグループ名、または「ホームグループ」を意味するトークンまたは {homegrp}/UserEntry などを組み込むことができると思います。

少しふざけた内容でしたら申し訳ありませんが、要点を理解していただければ幸いです。(私が最後まで読んだとは思わないので、以前の回答でこれについて話していた場合はお詫びします...)

于 2009-11-03T01:58:56.887 に答える
0

1 - 各ユーザーに固有のソルトを使用してパスワードを暗号化することをお勧めします。そうすれば、システムが危険にさらされた場合でも、ハッカーはユーザーのパスワードを利用できなくなります (彼らの側でさらにハッキングする必要はありません)。

http://phpsec.org/articles/2005/password-hashing.html (少し古いですが、良い情報があります)

2、3、4 - これらはすべて、幅広い Web 言語で可能です。最初にデータベース設計を読み、どのような正規化とテーブル スキーマがあなたの状況に理想的かを理解することをお勧めします。将来、管理者ユーザーに権限を追加することにした場合は、最初からそのための設計を行い、将来の頭痛の種を回避しながら、現在の要件内に収まるようにすることができます。

http://dev.mysql.com/tech-resources/articles/intro-to-normalization.html http://www.peachpit.com/articles/article.aspx?p=30885

于 2009-10-11T18:26:09.727 に答える
-1

2..はい

3.. アクセス許可の数が限られている場合、これは簡単です。

4.. これは数年前に書いたもので、大企業で頻繁に使用されています。スキーマに関する詳細情報が必要な場合は、私に連絡してください。

于 2009-10-06T18:07:32.837 に答える