Super
Super
组织:[EasyAbp](https://easyabp.io) 地点:GitHub 联系方式:[email protected] 使用场景:实现 Entity UI 模块动态生成 RazorPages 的表单模型;实现 Dynamic Entity 模块的(开发者可于运行时在线编写的)业务逻辑脚本
目前,配置注册机制主要用于对微信回调的签名认证,因此可以只以MchId->ApiKey进行存储。 * 建议在应用程序启动时,显式注册商户配置,具体的实现方式可能是:在`IWeChatPayOptionResolveContributor`增加获取所有配置的方法,在应用程序启动时,获取和遍历它们,进行注册。 * 并且提供运行时补充注册的方式,例如应用程序运行中新增了一个租户,它拥有一套独立的配置,则需要自动把它注册进去。 * 补充注册的方法可能导致在这套配置首次被使用之前,由于缺少配置,不能处理微信的回调,因此还是需要提供“运行时显式注册”的方法,对此有更高要求的开发者可以使用这个方法,在运行时对新增的配置进行显式注册。 * 在注册时难免碰到相同的MchId提供不同的ApiKey的情况,我们应该考虑每个MchId下存储多个ApiKey,在对微信回调进行签名认证时,从第一个ApiKey开始试用,碰到第一个正确的ApiKey,则将它移到第一位。 以上构想提供 @GameBelial 参考。
> 支付结果通知接口、退款通知接口,应在路由上传入AppId 已了解,微信调用回调地址时会传入appid参数。
> 所有的商户(AppId)应有注册机制 注册机制是为了提供足够信息进行签名验证,也可考虑设计成可替换的验证器
是否考虑使用setting,在全局、租户级别提供“商户配置”,并且允许开发者对此配置器进行重写或替换,从而实现更复杂场景?
可考虑: * 主动请求微信时:默认从setting中获取配置,支持手动临时覆盖默认配置 * 接收微信回调时:从商户注册表中读取配置,目前用于签名验证
> @gdlcf88 考虑使用单独的表存储,存储在 ISettingManager 限制很多,性能也有不少问题。 我们的框架模块最好不设计实体,保持轻量
What is the CAP Header in ABP for?
``` [20:09:06 DBG] Build started... [20:09:24 DBG] Build failed. Use dotnet build to see the errors. ``` Fix the code and run migration again.
Maybe this generation step is fine but not necessary. Since the `[Area(MyProjectRemoteServiceConsts.ModuleName)]` can be added to the [abstract controller class](https://github.com/abpframework/abp/blob/dev/templates/module/aspnet-core/src/MyCompanyName.MyProjectName.HttpApi/MyProjectNameController.cs). What do you think @wakuflair?