-
Notifications
You must be signed in to change notification settings - Fork 140
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
小提议:可否重新设计 auth.Validator? #35
Comments
也许还能更简单些。 // Validator 验证器
type Validator interface {
Validate(verifier auth.Verifier) error {
}
// HTTP 验证器
type HTTPValidator struct {
headers ...
body ...
parsedErr error
}
func NewHTTPValidator(headers http.Header, body []byte) Validator {
// parsing http context
...
return HTTPValidator{parsedErr: err, ...}
}
func (this *HTTPValidator) Validate(verifier auth.Verifier ) error {
if this.parsedErr != nil {
return this.parsedErr
}
serialNo, msg, sign := this.getVerifyArgs()
return verifier.Verify(serialNo, msg, sign)
} |
感谢反馈。 的确一开始 Validator 的设计是专门为了 「API 应答」设计的,后来加入「通知请求」的检查后尽管检查逻辑依旧相同,但是输入不再是 http.Response。 我们评估下这种情况如何处理更合适。 |
我觉得还是 |
关于第二种 首先是 其次这种模式看上去更适合于「有多个 type SomeHTTPHandler struct {
verifiers []auth.Verifier
...
}
func (h *SomeHTTPHandler) verify(header http.Header, body []byte) (err error) {
data := NewHTTPValidator(header, body)
for (v := range h.verifiers) {
if err = data.validate(v); err != nil {
return fmt.Errorf("Verify failed: %w", err)
}
}
return nil
} 而在我们SDK的场景中,目前看应该不会有多个 |
先关闭了,有问题再打开 |
我在修复 notify/handler 的过程中发现有些坏味道代码,可能当初的设计是非常好的,只是加上 notify 后变得不那么合适了。
我个人感觉可以更新一下 Validator 的定义。
目前的定义是这样:
可否改为类似下面的 :
然后不同的业务上下文各自实现自己的 Validatable ,比如 http.Response 和 notify 就可以拆到各自的模块,互不相干。
两者在业务上确实也没啥关联,仅仅只是重用了一套验证逻辑(当然,也能重用一些小代码)。
The text was updated successfully, but these errors were encountered: