1

私は最近 ( http://vimeo.com/68390507 ) の講演を見ました。講演者は、EnableViewStateMac=false を決して設定しないように、非常に真剣に何度も言っています。

Enterprise Web Library を使用しているときに、EnableViewStateMac が false に設定されていることに気付きました。これを補うためにEWLで何が行われていますか? 安全であることをどのように信頼できますか?

4

2 に答える 2

2

EWL は現在 Web フォーム (およびビュー ステート) に依存していますが、それは弱い依存関係であり、私たちのロードマップでは依存関係を完全に排除する必要があることに注意してください。EWL は、 と を使用してビュー ステートの保存と読み込みを完全にオーバーライドします。Page.SavePageStateToPersistenceMediumこれは、ページ上のコントロールが独自の [おそらく安全でない] 状態を保存できPage.LoadPageStateToPersistenceMediumないことを意味します。

以下は、EWL がビュー ステートに保存するものの完全なリストです。

  • EWL「ページ状態」。これは、ユーザーがページにとどまっている限り保持する必要があるデータですが、データベースやその他の永続的なストレージに保存するべきではありません。たとえばEwfTable、ページの一部を更新できるように中間ポストバックに保存する必要がある 、またはフォーム フィールド値の現在のアイテム表示制限。このタイプのデータは、ユーザーによって直接操作され、ありふれた形式のフィールド値ほど秘密ではありません。実際、非表示フィールドにさらにオープンに格納することを検討しています。これにより、JavaScript がポストバックなしで操作できるようになります。

  • 「フォーム値ハッシュ」。これは、ページがレンダリングされた時点でのすべてのフォーム フィールド値のハッシュです。ポストバックで使用され、ユーザーが最後にページをロードしてからデータが変更されたかどうかをユーザーに通知します。このハッシュがハッキングされた場合、2 つのことが起こる可能性があります。まず、データが変更されていない場合でも、ユーザーは「同時実行エラー」を受け取る可能性があります。次に、データが変更された場合でも、ユーザーは同時実行エラーを受け取ることができませんでした。この 2 番目のケースは悪いように聞こえるかもしれませんが、実際の Web アプリケーションのほとんどは、そもそもこの種の同時実行性チェックを備えていないことを覚えておいてください。

  • 最後のポストバックで失敗したデータ変更の ID。これは、null、空、またはページの HTML に存在するポストバック ID の 1 つに等しいかのいずれかであり、検証エラーを再表示するために、特定のケースでデータ変更を再実行するために使用されます。ハッキングの最悪の結果は、別の、しかしトリガー可能な一連の検証エラーが表示されることです。

于 2014-03-01T16:37:20.837 に答える