多くの場合、ユーザーに表示されるもの(Webページなど)は、部分的にセキュリティチェックに基づいています。私は通常、ユーザーレベルのACLセキュリティをシステムのビジネスロジックの一部と見なしています。ビューがセキュリティを明示的にチェックして条件付きでUI要素を表示する場合、ビジネスロジックを含むことでMVCに違反していますか?
多くの場合、ユーザーに表示されるもの(Webページなど)は、部分的にセキュリティチェックに基づいています。私は通常、ユーザーレベルのACLセキュリティをシステムのビジネスロジックの一部と見なしています。ビューがセキュリティを明示的にチェックして条件付きでUI要素を表示する場合、ビジネスロジックを含むことでMVCに違反していますか?
回答:
2つのタイプのセキュリティ条件があり、1つはモデルにあり、もう1つはビューにあります。ビューは、現在のユーザーの権限に応じて関連要素の表示を制御しますが、モデルは、基になるデータへのアクセスを制御します。モデルに適切な検証/検証がすべて含まれている限り、ビューが欠落している場合でも、セキュリティは維持されます。
ビューは異なるレベル/ロールで変更する必要があるため、通常は両方が必要です。コントローラーはビューを変更する関連データを送信しますが、ビューはそのデータを使用してコンテンツを非表示/表示して適切なユーザーに表示する必要があります。
そのため、ほとんどのテンプレートフレームワークには条件付き要素(ハンドルバーの例)があります。
{{#if isCurrentUserAdmin}}
....
{{/if}
つまり、適切な部分が正しい場所にある限り、それは違反ではないということです。
はいといいえ。
実際のセキュリティ決定がビューによって行われた場合、はい、MVCに違反しています。ただし、ビューが実際の決定をモデルに委任する場合は、問題ありません。モデルからの情報に基づいて、表示する要素を決定するビューに問題はありません。
たとえば、「編集者」権限を持つユーザーにのみ表示される「編集」ボタンがある場合、ビューが現在のユーザーが誰であるか、および「編集者」権限を持っているかどうかをモデルに尋ねることは問題ありません。この情報を使用して、ボタンを表示するかどうかを決定します。ただし、ビューが認証および承認ロジック自体を実行することである場合は、MVCに違反していることになります。
いいえと言います。
しかし、@ rvcoutinhoが言ったのとは別の理由で(彼はwikipediaを引用しているので、私の考えが間違っていると感じています)
セキュリティビットのスイッチを使用できるという点で、関連するセキュリティ上の懸念事項は、ビューに与えられたモデルによって共有されるはずです(この理由でViewModelを使用したい組み合わせの数によって異なります)。
これにより、2層のセキュリティ検証が可能になります。UI層で通常のケースのポストバックが破壊されるだけでなく、モデルが自身の内部でセキュリティ情報を保持するようにモデルがセキュリティ情報を保持する悪質なアクターのサーバー層で、コントローラーが情報を渡すようにします。すぐにそれを投げるモデル。
このような2層セキュリティは業界の標準であり、この方法では、セキュリティロジックが2か所にのみ存在する必要があるため、セキュリティロジックをコントローラーに配置するとすぐに、それが追加されます。 UIとモデル内(モデルは防御の最終ラインであり、デスクトップクライアントやサーバー管理ツールなどのMVC Webアプリ以外の用途で特に重要であるため、モデルに必要です)
いいえと言います。
通常、この種のセキュリティチェックはコントローラによって行われます。
ウィキペディアから:
コントローラは、関連するビューにコマンドを送信して、ビューのモデルの表示を変更できます
そして、私はそれがビューで直接行われるべきだとは思いません。たとえば、JavaScriptを介して行われる場合、セキュリティ上の問題になる可能性があります(JavaScriptを無効にして特権データにアクセスする可能性があります)。
もう一度、ウィキペディアから:
ビューは、モデルから出力表現を生成するために必要な情報を要求します。
この質問にはいくつかの問題があります。
if model.userCanEdit() ... endif
。UI要素を表示するだけの場合は問題ないと思います(とにかく、他にどのようにしますか?)。これらの要素にデータがある場合、モデルはコンテナーが空であることを確認する必要があります。そしてもちろん、権限データを取得するコードはビューの前に処理されているはずなので、ここではモデルへのアクティブなアクセスはありません。