为了账号安全,请及时绑定邮箱和手机立即绑定

CryptographicException:填充无效,无法删除,并且验证视图状态MAC失败

CryptographicException:填充无效,无法删除,并且验证视图状态MAC失败

森林海 2019-12-04 10:15:05
监视我的全局异常日志,无论我做什么都似乎无法消除此错误,我以为我终于摆脱了它,但又回来了。您可以在类似的帖子中看到错误的痕迹。有关环境的注意事项: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服务器上的问题提示中提供的摘录)

  • 怀疑带有第三方绑定的页面(搜索服务,会员计划...)

希望这可以帮助 ;-)


查看完整回答
反对 回复 2019-12-04
?
ITMISS

TA贡献1871条经验 获得超8个赞

您确定您的问题与加密相关,并且不是由ViewState太大引起的吗?如果ViewState是问题,则可以将其分块-在web.config中更改pages / MaxPageStateFieldLength的值


查看完整回答
反对 回复 2019-12-04
  • 3 回答
  • 0 关注
  • 738 浏览

添加回答

举报

0/150
提交
取消
意见反馈 帮助中心 APP下载
官方微信