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