3 回答
TA贡献1860条经验 获得超8个赞
对从错误消息中找到多个关键字的网页进行的调查表明,这种类型的错误是相对常见的,通常是随机的(至少在外观上),不幸的是很少包含明确的解决方法或解释...
许多相似但不同的情况的存在可能与许多不同的体系结构和基础配置有关,这可能导致加密层无法在请求页面中断言MAC(消息认证代码)的真实性:
服务器场设置
跨域/联合页面
第三方小部件库等
实际的ASP程序逻辑(当然)
关于这些错误报告的一个相对频繁的“标记”是提到资源请求(例如WebResource.axd)。
请注意,此类请求通常不会被记录(除非它们引起相对较少的关注,否则会增加日志文件的大小)。日志文件中的这种缺失以及它们经常被缓存的事实(以及错误的相对随机和不频繁发生)可能解释了错误的这种可能来源是如何“隐蔽”的。这也表明,在尝试重新创建错误时(在跟踪日志时,实时地进行跟踪等),防止Web浏览器进行缓存(或至少清除其最初的缓存)可能很有用。
简而言之,这里有一些想法和需要寻找的东西:
开始记录* .axd请求
尝试将此类axd请求与异常日志中的错误事件相关联
寻找带有资源引用的页面
如果在“服务器场”设置中,请确保所有实例都使用相同的密钥(显然,在多个IIS服务器上的问题提示中提供的摘录)
怀疑带有第三方绑定的页面(搜索服务,会员计划...)
希望这可以帮助 ;-)
TA贡献1871条经验 获得超8个赞
您确定您的问题与加密相关,并且不是由ViewState太大引起的吗?如果ViewState是问题,则可以将其分块-在web.config中更改pages / MaxPageStateFieldLength的值
- 3 回答
- 0 关注
- 731 浏览
添加回答
举报