3

私たちのサイトにはやや奇妙な問題があります。

一貫して、1 人の匿名* ユーザーから次のエラーが発生します。

例外の種類: System.FormatException

例外メッセージ: Base-64 文字配列の長さが無効です。

いくつかの調査の後、IIS ログが 2 つの異なる (ただし連続した) IP から発信された要求を示しているため、ユーザーは何らかの形式の負荷分散ファイアウォールを使用しているようです。

私が判断できることから、「ViewStateMAC」を無効にすると、この問題が解決するはずです。

しかし、私には確信が持てず、ユーザーと一緒にこれをテストする方法がないため、それを進めるのは少し気が進まない.

誰かが同様の問題を経験しましたか? 彼らにどのように対処しましたか？

サーバーの詳細:

単一の IP から実行される単一のサーバー (Win2003)。

アップデート：

私が判断できることから、ViewStateMAC はサーバー側専用です。私の問題は、クライアントが複数の IP を持つ単一のページをポストバックしたことが原因です。

* ただし、IIS ログから決定された同じ 2 つの IP から。ユーザーに悪意もありません。

4

2 に答える 2

3

クライアントの要件とこれらに関するガイダンスの欠如により、過剰な量のコントロール、特に各ページで GridView を使用するアプリケーションで、異常な量のこれらのエラーが発生しています。

明らかな原因はビューステートの長さで、極端な場合には +50k 文字の長さでした。これは限られたユーザーのみが使用する管理アプリケーションであるため、最初は、この優れた (少し古い) 記事で概説されているソリューションの適応バージョンを使用してビューステートをセッションに移動することで、これを完全に解決しました: http://msdn.microsoft .com/en-us/magazine/cc163577.aspx しかし、これにより、戻るボタンやタブ ブラウジングを使用しているユーザーに問題が発生しました。

次に、追加のロギング コードを追加し、問題が実際にエラーの内容であることを確認しました。base-64 でエンコードされた文字列は、4 で割り切れる長さでなければなりません。このエラーが発生したときは、決してそうではありませんでした。一部のプロキシおよび/またはファイアウォールは、ある時点でビューステート文字列を切り捨てるだけであると想定されていました。次に、ASP.NET の ViewStateChunking を使用して、フィールドを複数の非表示フィールドに分割しました。この解決策は引き続き監視しています。

ただし、最近、有効な長さのviewstateフィールドでエラーが発生しましたが、これでは__EVENTVALIDATIONフィールドの長さが無効でした。

これが発生したページには、「+」記号 (電話番号) が含まれるフィールドがあります。現在、これらすべてが元の文字列の無効なエンコードによって引き起こされている可能性があるかどうかを調べています (+ 記号はベースで特別な意味を持っているため)。 -64 エンドデッド弦)。

于 2010-01-22T12:46:58.267 に答える
1

viewstatemac を無効にしても問題は解決しません。ViewStateMac の障害は、ユーザーが複数の IP アドレスからアクセスしている場合ではなく、複数の Web サーバーがある場合に発生します。

ひょっとして viewstateuserkey を使用していませんか? それでも、別の例外が発生するため、それはロングショットです。

ユーザーが一貫して再作成できる場合は、フィドラーをインストールして、それが発生するまでリクエストをログに記録してから、それらを送信してもらいたいと思います。次に、自分の側から再生して、エラーが発生するかどうかを確認します。

彼らは IE を Mac で使用していませんか? フォーム フィールドの長さのバグにより、長いビューステートが破損します。

于 2008-12-05T11:07:24.587 に答える