許可設計
おそらく次のモードがあります:
ユーザーグループの役割権限
ユーザーグループの権限
ユーザー役割の権限
ユーザー権限
最近、他の人の設計方法では、追加、参照、削除、変更などの権限の値を表すのに「整数」が使用されており、それぞれ整数 1、2、4、8 に置き換えられているのを目にしました。ただし、方法はそれぞれ異なります。たとえば、次のとおりです。
1. 2 の n 乗を使用して、1、2、4、8、16 などの権限値のセットを形成します。ユーザーの権限値は整数の合計です。 7 =1 2 4、5=1 4 などのサブセット内。データベースから特定の権限を持つユーザーを取得する場合は、最初にこれらの権限値を追加し、合計が k であると仮定して、次に、ユーザーを判断する場合は、テーブルから * を選択し、ユーザー権限値 = k を選択します。 ? パーミッション値 k を取り出し、それぞれ k&1、K&2、K&4、k&16 を使用します。これが true の場合、「&」の右側の整数に等しいパーミッションがあることを意味します。たとえば、k&4 が true の場合、ユーザーは権限テーブルで 4 に等しい値を持つ権限を持ちます。
2. 素数 2、3、5、7、11... を使用して権限セットを作成します。ユーザーの権限は、210 = 2* などの整数の積になります。 3*5*7、この方法は非常に興味深いと思いますが、素因数を分解する方法に問題があります。ただし、ユーザーの権限の間には包括的な関係があると考えています。削除権限がある場合は、参照権限が必要です。そうでない場合は削除できません。ただし、これは複雑すぎてエラーが発生しやすいため、権限を「アトミック」にするのが最善だと思います。つまり、あるユーザーは削除の権限を持っていますが、閲覧の権限を持っていない場合、この矛盾を解決する鍵は、閲覧の権限を付与することです。ユーザーに権限を与えるときに彼に。
3. 整数の代わりに、「ベクター テーブル」メソッドを使用し (私が言ったことは必ずしも正しいとは限りません)、追加、参照、変更、削除など、考えられるすべての権限を特定の順序で配置します。 .. .、ユーザーの権限値は 100010100001....01 のような固定の 100 桁の文字列です。左からの各桁が操作権限に対応します。そのような権限がある場合、このビットの値は 1 になります。作者がユーザー許可値を 100 桁に固定した理由は、アップグレードの問題のためですが、これは十分科学的ではないと思います。たとえば、権限の数よりも少ないです。
権限ランキング表: 追加、参照、変更、削除。ユーザー A は追加と参照の権限を持っているため、権限の値は 11 です。ユーザー B は参照と変更の権限を持っているため、権限の値は 011 です。 C には、参照および削除の権限値が 0101 です。この設計の利点は、他の権限が権限テーブルに追加されても、ユーザー テーブルやロール テーブルに影響を与えないことです。
4. バックグラウンド管理で権限を列権限と操作権限の 2 つのカテゴリに分割しました。各列はディレクトリに対応し、操作権限は参照に細分化されます。追加、変更、削除は、ユーザーがシステムに入った後、まず列の権限があるかどうかを判断し、次に列の権限があるかどうかを判断するのは比較的簡単です。次に、ユーザーが所有するディレクトリ権限に対応するディレクトリを分解します。このディレクトリに、ユーザーが管理する権限を持つ (データベースから取得された) ディレクトリ配列が含まれている場合、ユーザーはこのディレクトリに入る権限を持ちます。しかし、操作権限を判断するのは少し面倒に思えますが、ファイルの追加、参照、変更、削除のルールは基本的に同じですが、違いは追加と削除をマージしたことです。たとえば、ファイル名は proAddEdit.php です。幸いなことに、ファイル ID を変更するときに渡す必要がある追加のパラメーターがあることがわかりました。そこで、この問題を解決するために正規表現を使用しました。オブジェクト指向の考え方やシステム開発におけるフレームワーク システムの使用に適応していないため、時代遅れです。
上記は私の大まかな理解と説明です。間違いがあれば、専門家からの意見をいただければ幸いです。