验证回调通知事件签名提示：Signature does not match about dotnetcore.skit.flurlhttpclient.wechat HOT 7 CLOSED

字面意思，签名错误。

可能传参错误、混用了不同商户号（即用商户A去验签商户B的回调）等原因。

请贴下完整代码看看。

from dotnetcore.skit.flurlhttpclient.wechat.

目前还没支持多商户号，只配置了一个商户号，应该不是混用的原因。
这是Controller:

这是service：


后面的 DecryptEventResource 方法是可以解密出来数据的

from dotnetcore.skit.flurlhttpclient.wechat.

你应该使用收到的原始数据验签，而不是先反序列化后再序列化回 JSON 字符串 —— 你无法保证你序列化出来的结果跟你收到的是一模一样的。

from dotnetcore.skit.flurlhttpclient.wechat.

原来是这样，感谢大神指点！

因为一直读不到Request.Body,用 Sample 里读取body的方式也不行,最后无奈选择了这种方式...我再研究下

from dotnetcore.skit.flurlhttpclient.wechat.

定位到了问题，我定义input的时候字段的顺序与官方文档的顺序的不一致，将顺序修改成一样后，还是使用上面的方式将input反序列化后验签，可以通过了！
感谢大神指点~

from dotnetcore.skit.flurlhttpclient.wechat.

定位到了问题，我定义input的时候字段的顺序与官方文档的顺序的不一致，将顺序修改成一样后，还是使用上面的方式将input反序列化后验签，可以通过了！ 感谢大神指点~

不建议你这么搞。以后微信突然调整字段顺序了你怎么办？或者人家传给你的 JSON 里突然多了空格怎么办？

{ "key1": "value1", "key2": "value2" }

{"key2":"value2","key1":"value1"}

虽然一个有空格一个没空格、键顺序也不一样，但从数据的角度上讲，这俩 JSON 完全一样。可从字符串上看，这就是俩不同的字符串，当然签名结果会不一样。

REF: https://pay.weixin.qq.com/docs/merchant/development/interface-rules/signature-verification.html

微信官方也强调了，要使用原始报文主体验签。

from dotnetcore.skit.flurlhttpclient.wechat.

好的，感谢大神指出问题~
现在框架使用的是 ASP.NET Core 8，读取 Request.Body 的方式应该是变化了，我再查查文档，优化成使用原始报文主体验签。

from dotnetcore.skit.flurlhttpclient.wechat.