[스프링 MVC] 검증(1) - Validation

스프링 MVC 2편의 강의 내용을 정리한 포스팅입니다.

---

검증

컨트롤러의 중요한 역할 중 하나는 HTTP 요청이 정상인지 검증하는 것이다. 클라이언트 검증만으로는 조작의 가능성이 존재하기 때문에 보안에 취약하고, 서버만으로 검증하면 즉각적인 고객 사용성이 떨어진다. 따라서 둘을 적절히 섞어 사용하되 최종적으로 서버 검증을 거치도록 설계해야 한다.

검증 직접 처리

로직

1. Map<String, String> errors = new HashMap<>();을 선언하여 오류를 보관할 변수를 지정하고 검증 시 오류가 발생하면 오류가 발생한 필드명을 key로, 오류 메시지를 value로 저장한다.(오류 원인이 특정 필드가 아니라 필드 범위를 넘어서는 오류라면 globalError를 key로 사용한다.) 이후 뷰에서 해당 데이터를 가지고 사용자에게 오류 메시지를 출력할 수 있다.

2. 고객이 입력한 데이터는 검증 오류가 발생해도 유지되어 다시 입력 폼을 보여줄 때 이용된다.

문제점
'가격은 1000원 이상이어야 한다'와 같이 규칙에 따른 검증은 가능하지만, 타입 오류 처리가 불가능하다. 가격을 검증하기 위해서는 해당 필드에 숫자가 들어와야 한다. 그런데 사용자가 숫자 필드에 문자를 입력했다면 오류가 발생하게 된다.

입력값을 컨트롤러의 파라미터로 넘기기 위해 숫자 필드에 문자를 대입하는 과정에서 발생하는 오류이기 때문에, 정작 검증 로직을 가지고 있는 컨트롤러는 호출되지도 못하고 400 오류가 발생하게 된다. 즉, 필드와 입력 값이 서로 다른 타입인 경우 바인딩이 불가능하다.
이에 따라 사용자가 입력한 값이 사라지게 되면서 어떤 내용을 입력함에 따라 발생한 오류인지 이해하기 어려울 수 있으므로 해당 입력 값도 관리가 필요한 경우가 있다.

BindingResult

스프링이 제공하는 검증 방법은 위의 문제점을 해결해 주는데, 핵심은 BindingResult에 있다.

BindingResult는 데이터 바인딩 및 오류를 관리하는 인터페이스인 Errors를 상속받는 인터페이스로, 바인딩 결과를 처리함으로써 검증 오류를 보관하는 객체이다. 해당 객체는 DataBinder 클래스의 getBindingResult() 메서드를 통해 생성될 수도 있고, 직접적으로 구현될 수도 있다.

규칙이 있다면 BindingResult를 컨트롤러를 파라미터로 넘길 때 사용자의 입력 데이터를 저장할 파라미터의 바로 다음에 와야 한다는 것이다.


FieldError, ObjectError 클래스

BindingResult는 addError() 메서드를 이용해 직접 에러를 추가할 수 있도록 구현해 놓았는데, 이때 addError()의 파라미터로 들어가는 타입은 ObjectError이다.

ObjectError는 오류 발생 원인이 특정 필드에 있는 것이 아닌 전체 예외(global error)인 경우까지도 캡슐화한다. 그에 반해 FieldError는 특정 필드에 의해 발생한 오류를 캡슐화하는 클래스로, ObjectError를 상속받는다.

각 클래스의 생성자는 다음과 같다.

public ObjectError(
 String objectName, //오류가 발생한 객체 이름
 String defaultMessage //기본 오류 메시지
)

public ObjectError(
 String objectName,
 @Nullable String[] codes, //메시지 코드
 @Nullable Object[] arguments, //메시지에서 사용하는 인자
 @Nullable String defaultMessage
)

public FieldError(
 String objectName,
 String field, //오류 필드
 String defaultMessage
)

public FieldError(
 String objectName,
 String field,
 @Nullable Object rejectedValue, //사용자가 입력한 값(거절된 값)
 boolean bindingFailure, //타입 오류와 같은 바인딩 실패인지, 검증 실패인지에 대한 구분 값
 @Nullable String[] codes,
 @Nullable Object[] arguments,
 @Nullable String defaultMessage
)

BindingResult에 검증 오류를 적용하는 방법

1. 스프링이 FieldError를 생성하여 주입 (@ModelAttribute의 객체에 타입 오류 등으로 바인딩에 실패하는 경우)

2. 개발자가 직접 주입 (바인딩에는 성공했으나 비즈니스 로직 조건에 안 맞는 경우)
3. Validator 사용

오류 코드와 메시지 처리

v1. FieldError, ObjectError 이용

@PostMapping("/add")
public String addItemV1(@ModelAttribute Item item, BindingResult bindingResult, RedirectAttributes redirectAttributes, Model model) {
    if (item.getPrice() == null || item.getPrice() < 1000 || item.getPrice() > 1000000) {
        bindingResult.addError(new FieldError("item", "price", item.getPrice(), false, new String[]{"range.item.price"}, new Object[]{1000, 1000000}, null));
    }
}

해당 예시의 codes 파라미터(range.item.price)는 에러 메시지를 관리하는 properties 파일에 추가된 메시지 코드로, 가격의 유효 범위를 벗어났음을 알리는 메시지를 담고 있다.

v2. BindingResult가 제공하는 메서드 이용 & 오류 코드 자동화
v1에서는 BindingResult 객체를 만들기 위해 FieldError 또는 ObjectError 객체를 직접 생성한 뒤 넘겨주는 과정이 필요했다.

하지만 BindException이 제공하는 메서드인 rejectValue(), reject()를 이용하면 코드를 단순화할 수 있다.

(BindException은 BindingResult의 구현체)

public void rejectValue(
 @Nullable String field, //오류 필드명
 String errorCode, //MessageResolver가 식별하는 오류 코드
 @Nullable Object[] errorArgs, //오류 메시지의 파라미터 값
 @Nullable String defaultMessage //오류 메시지를 찾을 수 없을 때 사용하는 기본 메시지
)

오류 발생 원인에 따라 FieldError 또는 ObjectError를 선택했듯이 필드에 의한 오류인 경우 rejectValue()를, 그 외 포괄적인 오류인 경우 reject()를 선택하면 된다.

@PostMapping("/add")
public String addItemV2(@ModelAttribute Item item, BindingResult bindingResult, RedirectAttributes redirectAttributes, Model model) {
    if (item.getPrice() == null || item.getPrice() < 1000 || item.getPrice() > 1000000) {
        bindingResult.rejectValue("price", "range", new Object[]{1000, 1000000}, null);
    }
}

FieldError를 생성할 때 item 객체를 넘겨준 것과 달리 rejectValue() 메서드에서는 객체를 넘기지 않고도 정상적으로 동작한다.

BindingResult는 검증해야 할 객체의 바로 다음으로 따라오기 때문에 이미 검증해야 할 객체를 알고 있다. 따라서 객체를 직접 주입해주지 않아도 파악이 가능한 것이다.

오류 코드(메시지)의 우선순위
v2에서 바뀐 점이 다른 메서드를 이용한 것도 있지만 메서드가 바뀜과 동시에 오류 코드가 단순화되었음을 알 수 있다.

(range.item.price → range)

하지만 동작에는 문제가 없는데, 이는 MessageCodesResolver가 오류를 구성하는 방법에 따른 결과이다.

오류 코드를 만들 때 자세히 만들 수도 있고, 단순하게 만들 수도 있다.

range: 범위 오류 입니다. //포괄적
range.item.price: 상품의 가격 범위 오류입니다. //구체적

단순하게 만들면 범용성이 좋아 두루 사용할 수 있지만, 메시지를 세밀하게 작성하기 어렵다. 반대로 너무 자세하게 만들면 범용성이 떨어진다. 따라서 기본적으로는 범용성으로 사용하다가 세밀하게 안내해야 하는 경우 구체적인 내용이 적용되도록 메시지에 단계를 두는 방법을 채택할 수 있다.

만약 range라는 메시지만 있었다면 해당 메시지를 선택해서 사용하고, range.item.price와 같이 객체명과 필드명을 조합한 세밀한 메시지 코드가 있을 경우 해당 메시지를 높은 우선순위로 사용하는 것이다.

MessageCodesResolver
그렇다면 MessageCodesResolver 인터페이스가 어떻게 오류를 구성하는지 살펴보자.
해당 인터페이스는 검증 오류 코드로 메시지 코드를 생성하며 주로 ObjectError, FieldError와 함께 사용된다.

1. 기본 메시지 생성 규칙 - ObjectError

객체 오류의 경우 다음 순서로 2가지 생성 
1.: code + "." + object name 
2.: code

예) 오류 코드: required, object name: item 
1.: required.item 
2.: required

2. 기본 메시지 생성 규칙 - FieldError

필드 오류의 경우 다음 순서로 4가지 메시지 코드 생성
1.: code + "." + object name + "." + field 
2.: code + "." + field 
3.: code + "." + field type 
4.: code

예) 오류 코드: typeMismatch, object name "user", field "age", field type: int 
1. "typeMismatch.user.age" 
2. "typeMismatch.age" 
3. "typeMismatch.int" 
4. "typeMismatch"

rejectValue(), reject()는 내부에서 MessageCodesResolver를 사용해 메시지 코드를 생성한다. ObjectError, FieldError의 생성자를 보면 String[] 타입으로, 오류 코드를 여러 개 가질 수 있음을 알 수 있다. 따라서 우선순위에 따라 순서대로 코드를 보관할 수 있다.

오류 코드 관리 전략
핵심은 구체적인 것에서 덜 구체적인 것으로, 즉 구체적인 것을 먼저 만들어주고 덜 구체적인 것을 나중에 만들게 되면 메시지 공통 전략을 편리하게 도입할 수 있다.
모든 오류 코드에 대해 일일이 메시지를 정의하면 관리하기가 어렵다. 따라서 크게 중요하지 않은 메시지는 범용성 있는 코드로 끝내고, 중요한 메시지는 구체적으로 적어 사용하는 방식이 효과적이다. 범용성 있는 코드는 재활용이 가능하기 때문이다.

스프링이 직접 만든 오류 메시지 처리
검증 오류 코드는 개발자가 직접 설정한 오류 코드와 스프링이 직접 검증 오류에 추가한 경우, 2가지로 나눌 수 있다.
후자의 경우 타입이 맞지 않아 발생하는 경우가 많은데, 해당 상황에서는 FieldError가 호출됨에 따라 4개의 메시지 코드가 생성될 것이다.
properties 파일에 typeMismatch와 관련된 메시지를 등록하지 않았다면 스프링이 생성한 기본 메시지가 출력되고, 등록한 경우 원하는 메시지를 단계별로 설정하여 출력하는 것이 가능하다.

v3. Validator 분리

컨트롤러에서 검증 로직이 차지하는 부분은 매우 크기 때문에, 별도의 클래스로 역할을 분리하는 것이 좋다.
스프링은 검증을 체계적으로 제공하기 위해 다음 인터페이스를 제공한다.

public interface Validator {
    boolean supports(Class<?> clazz);
    void validate(Object target, Errors errors);
}

검증 역할을 수행하는 클래스를 직접 만들어 컨트롤러 내 메서드에서 직접 호출할 수도 있지만, 해당 인터페이스를 이용해 만들면 검증기를 직접 호출하는 과정을 생략할 수 있다.

먼저 WebDataBinder에 검증기를 등록해야 하는데, 여기서 WebDataBinder는 웹 요청 파라미터를 자바 빈 객체에 바인딩하는 역할을 수행한다. 다음과 같이 Validator 인터페이스를 상속받아 검증기를 만들 수 있다.

@Component
public class ItemValidator implements Validator {
    @Override
    public boolean supports(Class<?> clazz) {
        return Item.class.isAssignableFrom(clazz);
    }

    @Override
    public void validate(Object target, Errors errors) {
        //검증 로직
    }
}

 

검증을 수행하려는 객체 앞에 @Validated 애노테이션을 붙여주면 WebDataBinder에 등록한 검증기를 찾아 대신 실행해 준다. 그전에 어떤 검증기를 실행할 것인지에 대한 구분이 필요한데, 이때 supports() 메서드를 통해 검증기 지원 여부를 확인하여 골라낼 수가 있다. 결과로 true가 반환될 경우 validate 메서드가 호출되어 검증을 수행한다.

@PostMapping("/add")
public String addItemV3(@Validated @ModelAttribute Item item, BindingResult bindingResult) {
}

@Validated 대신 @Valid를 사용할 수도 있다. @Validated는 스프링 표준, @Valid는 자바 표준 검증 애노테이션인데 @Valid를 사용하기 위해서는 build.gradle에 의존관계를 추가해주어야 한다는 차이점이 존재한다.