在網上搜尋了很久看了很多關于MAC驗證視圖狀態失敗的解決方法。大部分人都說是在頁里或web.config里加

EnableEventValidation="false" EnableViewStateMac="false" ViewStateEncryptionMode="Never" 這些屬性的設

置。但是這并不從根本上解決問題，相反這樣做了反而更加不安全。

　　為了解決問題我繼續收集資料，不經意的發現了一個網頁里講到一個Blog系統從NET1.1升級到NET2后，之前所生

成的所有cookies將會失效，因為NET2和NET1使用的machineKey不一樣。哈哈，真是恍然大悟啊！

WEB應用中經常遇到采用集群或負載均衡交換機等方式實現多服務器共同對外提供服務，分擔壓力。在這樣的環境下

如果Asp.Net程序執行時碰到如下中文錯誤：

“驗證視圖狀態 MAC 失敗。如果此應用程序由網絡場或群集承載，請確保 <machineKey> 配置指定了相同的

validationKey 和驗證算法。不能在群集中使用 AutoGenerate。”

或如下英文錯誤：

Validation of viewstate MAC failed. If this application is hosted by a Web Farm or cluster, ensure

that <machineKey> configuration specifies the same validationKey and validation algorithm.

AutoGenerate cannot be used in a cluster.

則說明多臺WEB服務器上的WEB應用程序沒有使用統一的machineKey導致的。

那么machineKey的作用是什么呢？

按照MSDN的標準說法：“對密鑰進行配置，以便將其用于對 Forms 身份驗證 Cookie 數據和視圖狀態數據進行加密

和解密，并將其用于對進程外會話狀態標識進行驗證。”

也就是說Asp.Net的很多加密，都是依賴于machineKey的設置，例如Forms 身份驗證 Cookie、ViewState的加密。

默認情況下，Asp.Net的配置是自己動態生成，validationKey和decryptionKey的默認值是AutoGenerate。如果單臺

服務器當然沒問題，但是如果多臺服務器負載均衡，machineKey還采用動態生成的方式，每臺服務器上的machinekey

值不一致，就導致加密出來的結果也不一致，不能共享驗證和ViewState，所以對于多臺服務器負載均衡的情況，一

定要在每臺站點配置相同的machineKey。至此真相水落石出，立刻在web.config中添加關于machineKey的配置項，并

手動設置其中的密鑰值，這里請注意，不同加密算法對于密鑰的最大字符長度是不同的，在這里能夠使用的有AES，

DES，3DES，SHA1，MD5，我只知道DES的密鑰字符長度為16，3DES長度為48，手動設置時密鑰長度必須等于其最大長

度，否則會出錯！至于密鑰的16進制值可以隨便輸入。

參考的web.config 中matchineKey配置：

? <system.web>
??? <machineKey validation="3DES" validationKey="319B474B1D2B7A87C996B280450BB36506A95AEDF9B51211"

decryptionKey="280450BB36319B474C996B506A95AEDF9B51211B1D2B7A87" decryption="3DES"/>
? </system.web>

好了，問題得已解決！希望廣大朋友遇到MAC驗證視圖狀態失敗的問題的時候，不要馬上把

EnableViewStateMac="false"設置成這樣就完事了。先分析什么原因導致了這個錯誤的發生，禁用掉

EnableViewStateMac驗證是可以解決問題，但這不是根本的，起碼是犧牲了一定的安全性！

轉載于:https://www.cnblogs.com/ljt-stone/p/9447095.html

總結

以上是生活随笔為你收集整理的验证视图状态MAC失败的解决办法的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。