ビューでのセキュリティ条件文の使用はMVCの違反ですか?


10

多くの場合、ユーザーに表示されるもの(Webページなど)は、部分的にセキュリティチェックに基づいています。私は通常、ユーザーレベルのACLセキュリティをシステムのビジネスロジックの一部と見なしています。ビューがセキュリティを明示的にチェックして条件付きでUI要素を表示する場合、ビジネスロジックを含むことでMVCに違反していますか?


代わりは何でしょうか?

1
一部の人がアンチパターンと見なしても、最高のセキュリティを提供するものを使用します。
zxcdw 2013年

回答:


6

2つのタイプのセキュリティ条件があり、1つはモデルにあり、もう1つはビューにあります。ビューは、現在のユーザーの権限に応じて関連要素の表示を制御しますが、モデルは、基になるデータへのアクセスを制御します。モデルに適切な検証/検証がすべて含まれている限り、ビューが欠落している場合でも、セキュリティは維持されます。

ビューは異なるレベル/ロールで変更する必要があるため、通常は両方が必要です。コントローラーはビューを変更する関連データを送信しますが、ビューはそのデータを使用してコンテンツを非表示/表示して適切なユーザーに表示する必要があります。

そのため、ほとんどのテンプレートフレームワークには条件付き要素(ハンドルバーの例)があります。

{{#if isCurrentUserAdmin}}
    ....
{{/if}

つまり、適切な部分が正しい場所にある限り、それは違反ではないということです。


4

はいといいえ。

実際のセキュリティ決定がビューによって行われた場合、はい、MVCに違反しています。ただし、ビューが実際の決定をモデルに委任する場合は、問題ありません。モデルからの情報に基づいて、表示する要素を決定するビューに問題はありません。

たとえば、「編集者」権限を持つユーザーにのみ表示される「編集」ボタンがある場合、ビューが現在のユーザーが誰であるか、および「編集者」権限を持っているかどうかをモデルに尋ねることは問題ありません。この情報を使用して、ボタンを表示するかどうかを決定します。ただし、ビューが認証および承認ロジック自体を実行することである場合は、MVCに違反していることになります。


2

いいえと言います。

しかし、@ rvcoutinhoが言ったのとは別の理由で(彼はwikipediaを引用しているので、私の考えが間違っていると感じています)

セキュリティビットのスイッチを使用できるという点で、関連するセキュリティ上の懸念事項は、ビューに与えられたモデルによって共有されるはずです(この理由でViewModelを使用したい組み合わせの数によって異なります)。

これにより、2層のセキュリティ検証が可能になります。UI層で通常のケースのポストバックが破壊されるだけでなく、モデルが自身の内部でセキュリティ情報を保持するようにモデルがセキュリティ情報を保持する悪質なアクターのサーバー層で、コントローラーが情報を渡すようにします。すぐにそれを投げるモデル。

このような2層セキュリティは業界の標準であり、この方法では、セキュリティロジックが2か所にのみ存在する必要があるため、セキュリティロジックをコントローラーに配置するとすぐに、それが追加されます。 UIとモデル内(モデルは防御の最終ラインであり、デスクトップクライアントやサーバー管理ツールなどのMVC Webアプリ以外の用途で特に重要であるため、モデルに必要です)


「コントローラーは関連するビューにコマンドを送信して、モデルのビューのプレゼンテーションを変更できる」というWikipediaの主張は、Model-View-Presenterに適しているようです。インタラクティブなモデルでは、フレーズが記述されているように見えるため、MVCでは1回だけです。ビューがレンダリングされると、ビューとコントローラーの間でそれ以上のアクションは行われません。
Robert Harvey

1
@RobertHarvey私はMVCの定義にステートメントが適合しないことに同意しますが、幸運なことに、これらの定義がエーテルからのように浮かぶため、正確性が確率ではなく複数の合意によって決定される業界で働いています誰もが自分の持ち帰りをすることを可能にする絶えず進化する基盤。またはもっとわかりやすく言えば、私はおそらくここの他のみんなと同じくらい間違っている。
ジミー・ホッファ

3
だからとにかく、人々はこの種のことについてあまりにも知識を深めていると思います。
Robert Harvey

1
@rvcoutinho私はまったく言っていませんが、私は文字通りでした。あなたはあなたの側に参照を持っています、私が持っているすべては私の意見です、そして私の心の中でそれは私がそれを言及した理由である私が間違っている可能性があることを意味します。私が言及したことはありませんが、私の意見は共有する価値があるほど説得力があると思うので、私が言ったように、私はおそらく間違っているという事実に関係なく、とにかくそれをしました。
ジミー・ホッファ

1
@rvcoutinho:実際、私はOPの質問に言及していました。:)ルールが何かを成し遂げることの邪魔にならない限り、ルールには何も問題はありません。
Robert Harvey

2

いいえと言います。

通常、この種のセキュリティチェックはコントローラによって行われます。

ウィキペディアから:

コントローラは、関連するビューにコマンドを送信して、ビューのモデルの表示を変更できます

そして、私はそれがビューで直接行われるべきだとは思いません。たとえば、JavaScriptを介して行われる場合、セキュリティ上の問題になる可能性があります(JavaScriptを無効にして特権データにアクセスする可能性があります)。

もう一度、ウィキペディアから:

ビューは、モデルから出力表現を生成するために必要な情報を要求します。


1
多くのソフトウェアシステムでは、要素の表示はユーザーのセキュリティレベルに依存します。ビューモデルでデータアイテムをゼロまたはnullに設定することにより、データアイテムの表示を抑制することができますが、データアイテムの名前または説明は引き続き表示されます。データアイテムの説明の表示を(実際的な方法で)禁止できる唯一の場所はビューです。
Robert Harvey

私は反対する傾向があります。ビューはデータを要求し、コントローラーはモデルを操作し、ビューは再びそれを表現します。ビューは、出力の表現のみを担当する必要があります。
rvcoutinho 2013年

ユーザーが見る必要のない視覚要素をビューが非表示にする必要があるのはこのためです。コントローラは、データの視覚的表現を作成する責任を負いません。ビューです。もちろん、表示しているものが非常にデリケートでビュー/ソースにも表示できない場合、コントローラーが行う必要があるのは別のビューを返すことです。
Robert Harvey

1
それが私のポイントです。ビューは異なる必要があります。私の理解する限り、ビューはデータの表現のみを処理するように見えます。表現とは、いつ表示するかではなく、どのように表示するかを意味します。まだあなたのコメントは完全に関連しています。
rvcoutinho 2013年

ええと、同じ表現を2つの異なるものに使用しているだけかもしれません。とにかく別のビューとは何ですか?しかし、私は最も重要な問題については同意していると思います。それがセキュリティに敏感な場合、ビューによって処理されるべきではありません。
rvcoutinho 2013年

1

この質問にはいくつかの問題があります。

  1. 認証(彼がそう言っているこのユーザーですか)はビューの問題ではありません
  2. 許可(行うことを許可され、現在のユーザーですこれはであることをユーザに提示する内容に影響を及ぼす可能性があるため、ビューの懸念。したがって、編集ボタンを表示するコードは、のような条件で囲むことができますif model.userCanEdit() ... endif
  3. ユーザーが持つ承認属性の決定。これはビジネスロジックであり、モデルに配置する必要があります。(たとえば、「編集」権限では2000の評判が必要です。または、作成者またはモデレーターである必要があります)

0

UI要素を表示するだけの場合は問題ないと思います(とにかく、他にどのようにしますか?)。これらの要素にデータがある場合、モデルはコンテナーが空であることを確認する必要があります。そしてもちろん、権限データを取得するコードはビューの前に処理されているはずなので、ここではモデルへのアクティブなアクセスはありません。


0

ビューがセキュリティを明示的にチェックして条件付きでUI要素を表示する場合、ビジネスロジックを含むことでMVCに違反していますか?

はい、それはMVCの違反です。

ビューは要素を表示するためだけにあり、ロジックはモデル内にある必要があります。ビューに何かをさせる(あなたの場合、セキュリティをチェックする)ことにより、そこにロジックを配置します。


次に、ビューは編集ボタンのようなものを表示するかどうかをどのようにして知るのでしょうか?
Matt S

@MattSプレゼンターはビューで関数を呼び出し、そのボタンを表示または非表示にします(モデルの状態に応じて)。
BЈовић
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.