そうです、ページの保護と要素の保護は異なります。
私の意見では、実際には、コードをロールまたはユーザーに関連付けることは、実際には間違ったアプローチだと思います。代わりに、権限を要素とページに関連付けてから、役割をそれらの権限に関連付けます。そしてもちろん、ユーザーには役割が割り当てられます。
3つすべてを用意することが重要です：
- ユーザー
- 役割
- 権限<-これはあなたが見逃しているものです
権限は、要素やページを保護するものであり、役割やユーザーではありません コードには、どのユーザーまたはロールが存在するか（必要がないため）、手がかりがないようにする必要があります。アクセス許可の名前だけです。
ユーザーがログインすると、私はその役割を取得します。次に、それらの役割に割り当てられているすべてのアクセス許可（単に文字列値のリスト）を取得します。
たとえば、私が持っているかもしれないページに：
- アイテムを追加
- アイテムを表示
- アイテムを削除
そのページをコーディングするとき、実際には、類似した名前のアクセス許可文字列（addItem、viewItem、deleteItem）を使用してこれらの各要素を保護します。
<cfif listContainsNoCase( session.permissions, 'addItem' )>
<!--- code to add item --->
</cfif>
（注：これにはカスタムタグまたは関数を使用することをお勧めしますが、例として、上記は正常に機能します）。
このようにすると、最大限の柔軟性と抽象化が実現します。役割に基づいて要素を保護する場合は、自分自身を制限します：
- 新しい役割を追加するには、多くのコード変更が必要になります！
- ロール間で権限を変更するには、多くのコード変更が必要です！
上記のように行う場合、「addItem」権限は常に「アイテムの追加」ロジックにある必要があるため、コードベース内でセキュリティコードを変更する必要はありません。 :)
ここで、すべてのユーザーロールと選択したいくつかの管理者権限を持つ「マネージャー」タイプのロールを作成する必要がある場合は、そのロールを作成し、適切な権限（addItemとeditItemであるが、deleteItemではない）を割り当てるだけです。 。バム！これで、コードを変更しないユーザーに割り当てるマネージャーの役割ができました。 ！
コードに「ユーザーはこの役割」タイプのものをまき散らした場合、新しい役割「マネージャー」を許可するには、コードをどこでも編集する必要があります。
意味がありますか？
=）