迁移至Azure的Bot Channels Registration在Cortana中返回Forbidden问题排查

咱们一步步来拆解你的问题，先明确关键信息，再给出针对性的排查方向：

首先可以确定：2018年3月31日之后，旧版https://dev.botframework.com/bots上的Bot服务确实会被永久停用，官方当时推动迁移就是为了让用户切换到Azure托管的Bot Channels Registration服务，所以你完成迁移后，原旧Bot就不再接收流量，所有请求应该都转到新的Azure部署上——这部分你的理解是完全正确的。

既然Teams能正常调用、本地ngrok也能跑通Cortana，说明Bot的核心逻辑没问题，问题大概率出在Azure App Service的配置或Cortana频道的身份验证环节，给你列几个优先级较高的排查点：

• App Service的身份验证/授权配置：打开Azure App Service的「身份验证」面板，检查是否启用了“需要身份验证”的强制规则。Cortana的请求是服务端到服务端的调用，不需要用户登录凭证，如果App Service强制要求用户身份验证，就会直接拦截这类请求返回403。建议把这里的规则改成“允许匿名请求”，Bot自身的身份验证由SDK的BotAuthenticator来处理。
• Cortana频道的关联状态：进入Bot Channels Registration的频道管理页面，先删除Cortana频道，再重新添加并完成配置，确保消息端点填写的是Azure App Service的完整HTTPS地址（格式应该是https://<你的应用服务名称>.azurewebsites.net/api/messages）。有时候迁移后频道配置会出现隐性失效，重新关联能解决这类问题。
• App Service的IP防火墙限制：检查App Service「网络」面板里的IP防火墙规则，有没有设置严格的白名单却遗漏了Cortana服务的官方IP段。Cortana的Bot请求来自微软的固定IP范围，如果这些IP没被加入白名单，就会被防火墙拦截返回403。
• Node.js V3 SDK的身份验证配置：确认Bot代码里的Microsoft App ID和密码，和Bot Channels Registration门户里的配置完全一致。另外，V3 SDK针对Cortana有特定的身份验证逻辑，检查BotAuthenticator的配置是否正确启用了对Cortana请求的签名验证——虽然Teams能正常运行，但Cortana的签名规则可能有细微差异。
• Azure服务状态排查：因为问题是近两日才出现的，可以查看Azure的服务健康页面，看看是否有Cortana或Bot Service相关的故障通知，微软的服务端更新偶尔会导致临时的兼容性问题。

如果以上排查都没问题，还可以在App Service的「日志」面板开启详细日志，查看具体的403错误日志信息，里面会有更明确的拦截原因，方便进一步定位问题。

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