Spring validation 不断验证错误的参数

Spring validation keeps validating the wrong argument

我有一个带有 Web 方法的控制器,如下所示:

public Response registerDevice(
    @Valid final Device device, 
    @RequestBody final Tokens tokens
) {...}

还有一个如下所示的验证器:

public class DeviceValidator implements Validator {

    @Override
    public boolean supports(Class<?> clazz) {
        return Device.class.isAssignableFrom(clazz);
    }

    @Override
    public void validate(Object target, Errors errors) {
        // Do magic
        }
    }
}

我正在尝试让 Spring 验证拦截器生成的 Device 参数。但每次我尝试时,它都会验证 tokens 参数。

我已经尝试使用 @InitBinder 来指定验证器,@Validated 而不是 @Valid 并注册 MethodValidationPostProcessor 类。到目前为止没有运气。

要么根本没有调用验证器,要么在验证设备参数时验证了令牌参数。

我正在使用 Spring 4.1.6 和 Hibernate 验证器 5.1.3。

任何人都可以提供任何关于我做错了什么的线索吗?我整个下午都在网上搜索,试图解决这个问题。无法相信 spring 的验证区域仍然像 5 年前一样混乱:-(

好的。经过两天的各种变化,现在已经解决了它。如果有一件事情 Spring 的验证可以让你做 - 它提出了一系列令人难以置信的事情,但这些事情不起作用!但回到我的解决方案。

基本上我需要的是一种手动创建请求映射参数、验证它们然后确保无论成功还是失败,调用者始终收到自定义 JSON 响应的方法。事实证明,这样做比我想象的要难得多,因为尽管博客 post 和 Whosebug 的答案数量众多,但我从未找到完整的解决方案。因此,我努力概述了实现我想要的目标所需的每一块拼图。

注意:在下面的代码示例中,我概括了事物的名称以帮助阐明什么是自定义的,什么不是。

配置

虽然我读过的几篇博客 posts 谈到了各种 classes,例如 MethodValidationPostProcessor,但最后我发现除了 [=] 之外我不需要任何设置16=] 注释。默认解析器等证明是我需要的。

请求映射

我的最终请求映射签名如下所示:

@RequestMapping(...)
public MyMsgObject handleRequest (
    @Valid final MyHeaderObj myHeaderObj, 
    @RequestBody final MyRequestPayload myRequestPayload
    ) {...}

您会在这里注意到,与我找到的几乎每个博客 post 和示例不同,我有两个 object 被传递给该方法。第一个是我想从 headers 动态生成的 object。第二个是 JSON 有效载荷的反序列化 object。其他 objects 可以很容易地包含在内,例如路径参数等。在没有下面代码的情况下尝试这样的事情,你会得到各种各样奇怪而奇妙的错误。

让我痛苦的棘手部分是我想验证 myHeaderObj 实例,而不是验证 myRequestPayload 实例。解决起来很头疼。

同时注意 MyMsgObject 结果 object。这里我想 return 一个 object 将被序列化为 JSON。包括异常发生的时间,因为此 class 包含除 HttpStatus 代码之外还需要填充的错误字段。

控制器建议

接下来我创建了一个 ControllerAdvice class,其中包含验证绑定和一般错误陷阱。

@ControllerAdvice
public class MyControllerAdvice {

    @Autowired
    private MyCustomValidator customValidator;

    @InitBinder
    protected void initBinder(WebDataBinder binder) {
        if (binder.getTarget() == null) {
            // Plain arguments have a null target.
            return;
        }
        if (MyHeaderObj.class.isAssignableFrom(binder.getTarget().getClass())) {
            binder.addValidators(this.customValidator);
        }
    }

    @ExceptionHandler(Exception.class)
    @ResponseStatus(value=HttpStatus.INTERNAL_SERVER_ERROR)
    @ResponseBody
    public MyMsgObject handleException(Exception e) {
        MyMsgObject myMsgObject = new MyMsgObject();
        myMsgObject.setStatus(MyStatus.Failure);
        myMsgObject.setMessage(e.getMessage());
        return myMsgObject;
    }
}

这里发生了两件事。首先是注册验证器。请注意,我们必须检查参数的类型。这是因为 @RequestMapping 的每个参数都会调用 @InitBinder,而我们只需要 MyHeaderObj 参数上的验证器。如果我们不这样做,当 Spring 尝试将验证器应用于它对其无效的参数时将抛出异常。

第二件事是异常处理程序。我们必须使用 @ResponseBody 来确保 Spring 将 returned object 视为要序列化的内容。否则我们只会得到标准的 HTML 异常报告。

验证者

这里我们使用了一个非常标准的验证器实现。

@Component
public class MyCustomValidator implements Validator {

    @Override
    public boolean supports(Class<?> clazz) {
        return MyHeaderObj.class.isAssignableFrom(clazz);
    }

    @Override
    public void validate(Object target, Errors errors) {
        ...
        errors.rejectValue("fieldName", "ErrorCode", "Invalid ..."); 
    }
}

我仍然没有真正理解的一件事是 supports(Class<?> clazz) 方法。我本以为 Spring 使用这个方法来测试参数来决定是否应该应用这个验证器。但事实并非如此。因此 @InitBinder 中的所有代码决定何时应用此验证器。

参数处理程序

这是最大的一段代码。这里我们需要生成 MyHeaderObj object 传递给 @RequestMapping。 Spring 将自动检测此 class。

public class MyHeaderObjArgumentHandler implements HandlerMethodArgumentResolver {

    @Override
    public boolean supportsParameter(MethodParameter parameter) {
        return MyHeaderObj.class.isAssignableFrom(parameter.getParameterType());
    }

    @Override
    public Object resolveArgument(
        MethodParameter parameter, 
        ModelAndViewContainer mavContainer,
        NativeWebRequest webRequest, 
        WebDataBinderFactory binderFactory) throws Exception {

        // Code to generate the instance of MyHeaderObj!
        MyHeaderObj myHeaderObj = ...;

        // Call validators if the argument has validation annotations.
        WebDataBinder binder = binderFactory.createBinder(webRequest, myHeaderObj, parameter.getParameterName());
        this.validateIfApplicable(binder, parameter);
        if (binder.getBindingResult().hasErrors()) {
            throw new MyCustomException(myHeaderObj);
        }
        return myHeaderObj;
    }

    protected void validateIfApplicable(WebDataBinder binder, MethodParameter methodParam) {
        Annotation[] annotations = methodParam.getParameterAnnotations();
        for (Annotation ann : annotations) {
            Validated validatedAnn = AnnotationUtils.getAnnotation(ann, Validated.class);
            if (validatedAnn != null || ann.annotationType().getSimpleName().startsWith("Valid")) {
                Object hints = (validatedAnn != null ? validatedAnn.value() : AnnotationUtils.getValue(ann));
                Object[] validationHints = (hints instanceof Object[] ? (Object[]) hints : new Object[] { hints });
                binder.validate(validationHints);
                break;
            }
        }
    }
}

这个class的主要工作是使用它需要的任何手段来建立论点(myHeaderObj)。一旦构建完成,它就会继续调用 Spring 验证器来检查这个实例。如果有问题(通过检查 returned 错误检测到),它会抛出一个 @ExceptionHandler 可以检测和处理的异常。

注意 validateIfApplicable(WebDataBinder binder, MethodParameter methodParam) 方法。这是我在许多 Spring 的 class 中找到的代码。它的工作是检测是否有任何参数具有 @Validated@Valid 注释,如果有,则调用关联的验证器。默认情况下,Spring 不会为像这样的自定义参数处理程序执行此操作,因此我们需要添加此功能。认真 Spring ????没有 AbstractSomething ????

最后一块,显式异常捕获

最后我还需要捕获更明确的异常。例如上面抛出的MyCustomException。所以在这里我创建了第二个 @ControllerAdvise.

@ControllerAdvice
@Order(Ordered.HIGHEST_PRECEDENCE) // Make sure we get the highest priority.
public class MyCustomExceptionHandler {

    @ExceptionHandler
    @ResponseStatus(value = HttpStatus.BAD_REQUEST)
    @ResponseBody
    public Response handleException(MyCustomException e) {
        MyMsgObject myMsgObject = new MyMsgObject();
        myMsgObject.setStatus(MyStatus.Failure);
        myMsgObject.setMessage(e.getMessage());
        return myMsgObject;
    }
}

虽然从表面上看与一般异常处理程序类似。有一处不同。我们需要指定 @Order(Ordered.HIGHEST_PRECEDENCE) 注释。如果没有这个,Spring 将只执行与抛出的异常匹配的第一个异常处理程序。不管有没有更好匹配的handler。所以我们使用这个注解来确保这个异常处理程序优先于一般的处理程序。

总结

这个解决方案很适合我。我不确定我是否找到了最好的解决方案,并且可能有 Spring class 是我没有找到的可以提供帮助的东西。我希望这对遇到相同或相似问题的任何人有所帮助。