監視我的全局異常日志，無論我做什么都似乎無法消除此錯誤，我以為我終于擺脫了它，但又回來了。您可以在類似的帖子中看到錯誤的痕跡。有關環境的注意事項：IIS 6.0，.NET 3.5 SP1 單服務器 ASP.NET應用程序已經采取的步驟： <system.web> <machineKey validationKey="big encryption key" decryptionKey="big decryption key" validation="SHA1" decryption="AES" />在我所有頁面的頁面庫中 protected override void OnInit(EventArgs e) { const string viewStateKey = "big key value"; Page.ViewStateUserKey = viewStateKey; }同樣在頁面的源中，我可以看到所有ASP.NET生成的隱藏字段都正確地位于頁面頂部。
3 回答
桃花長相依
TA貢獻1860條經驗 獲得超8個贊
對從錯誤消息中找到多個關鍵字的網頁進行的調查表明，這種類型的錯誤是相對常見的，通常是隨機的（至少在外觀上），不幸的是很少包含明確的解決方法或解釋...
許多相似但不同的情況的存在可能與許多不同的體系結構和基礎配置有關，這可能導致加密層無法在請求頁面中斷言MAC（消息認證代碼）的真實性：
服務器場設置
跨域/聯合頁面
第三方小部件庫等
實際的ASP程序邏輯（當然）
關于這些錯誤報告的一個相對頻繁的“標記”是提到資源請求（例如WebResource.axd）。
請注意，此類請求通常不會被記錄（除非它們引起相對較少的關注，否則會增加日志文件的大小）。日志文件中的這種缺失以及它們經常被緩存的事實（以及錯誤的相對隨機和不頻繁發生）可能解釋了錯誤的這種可能來源是如何“隱蔽”的。這也表明，在嘗試重新創建錯誤時（在跟蹤日志時，實時地進行跟蹤等），防止Web瀏覽器進行緩存（或至少清除其最初的緩存）可能很有用。
簡而言之，這里有一些想法和需要尋找的東西：
開始記錄* .axd請求
嘗試將此類axd請求與異常日志中的錯誤事件相關聯
尋找帶有資源引用的頁面
如果在“服務器場”設置中，請確保所有實例都使用相同的密鑰（顯然，在多個IIS服務器上的問題提示中提供的摘錄）
懷疑帶有第三方綁定的頁面（搜索服務，會員計劃...）
希望這可以幫助 ;-）
ITMISS
TA貢獻1871條經驗 獲得超8個贊
您確定您的問題與加密相關，并且不是由ViewState太大引起的嗎？如果ViewState是問題，則可以將其分塊-在web.config中更改pages / MaxPageStateFieldLength的值
- 3 回答
- 0 關注
- 799 瀏覽
添加回答
舉報
0/150
提交
取消