Kentico升级12后GetAzureFile.aspx报badhashtext错误如何排查

按优先级从高到低排查以下项即可定位问题：

• 首先核对Azure存储配置一致性
  升级过程的web.config配置转换很容易覆盖自定义存储节点，逐一核对appSettings下的CMSAzureAccountName、CMSAzureSharedKey、CMSAzureBlobContainer、CMSAzureBlobEndPoint值是否与原环境完全匹配，只要存储密钥、访问端点配置错误，GetAzureFile.aspx生成的文件路径哈希就会和预期值不符，直接触发badhashtext拦截。
• 检查哈希校验相关全局配置
  1. 进入后台设置 > 系统 > 安全 > 内容安全板块，Kentico 12相比10版本调整了媒体接口的合法参数白名单，如果开启了「要求所有查询字符串参数都经过哈希验证」，旧版链接携带的参数不在新版白名单中时，即使salt一致也会判定哈希无效。
  2. 同板块下检查「哈希验证排除的URL」列表，确认升级过程没有清空原有媒体接口的排除规则，临时排查可先将/CMSPages/GetAzureFile.aspx加入排除列表测试，如果加完图片正常加载，即可确定是参数规则不匹配问题。
• 核对站点域名配置
  Kentico生成带哈希的文件链接时会将站点配置的默认域名纳入哈希计算范围，新环境使用了不同的访问URL时，需要确认后台站点管理 > 对应站点 > 站点域名中已经更新为新环境的正式域名、删除了旧环境的无效域名绑定，仅在IIS做域名绑定不会同步更新Kentico内部的域名配置，域名不匹配会直接导致哈希校验失败。
• 验证运行时实际加载的HashSalt值
  不要仅核对web.config中CMSHashStringSalt的文本值，要确认应用运行时实际读取到的值正确——升级过程的配置节点嵌套、转换错误都可能导致配置值被覆盖，可以临时在测试页输出CMS.Helpers.SecurityHelper.HashStringSalt核对运行时值和原环境是否一致。
• 排查请求链路的参数篡改问题
  检查web.config中的URL重写规则、WAF、反向代理配置，确认没有对GetAzureFile.aspx的查询字符串做截断、特殊字符转码操作，抓包对比实际到达应用后端的querystring和页面源码输出的图片链接querystring是否完全一致，参数被转码篡改时也会触发哈希校验失败。
• 处理版本兼容bug
  如果当前运行的是Kentico 12.0.0到12.0.14的早期版本，直接升级到12.0.15以上的累积更新即可，早期版本存在Azure存储媒体文件URL哈希计算逻辑与Kentico 10不兼容的已知bug，升级后无需额外操作即可兼容旧版生成的合法媒体链接。

排查时可以临时在web.config中将CMSDebugHashValues设置为true，访问报错的图片链接后，系统调试日志会明确输出哈希校验失败的具体原因，比如参数不匹配、域名不匹配或salt不一致，无需盲目试错。
注意单张重新保存图片只会重算单张文件在新规则下的链接哈希，不会更新页面、富文本字段中已经存储的旧版链接，所以这个操作无法解决存量链接的访问问题。

内容的提问来源于stack exchange，提问作者Rob M