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