Validation (검증)

검증 요구사항

타입 검증
- 가격, 수량에 문자가 들어오면 검증 오류 처리
필드 검증
- 상품명: 필수, 공백 X
- 가격: 1000원 이상 100만원 이하
- 수량: 최대 9999
특정 필드의 범위를 넘어서는 검증
- 가격 * 수량의 합은 10,000 이상

이전에는 잘못된 정보가 입력되어도 그냥 등록이 되거나, 400 오류가 발생하고 오류페이지를 보여줄 뿐이었다.

실제 서비스라면 고객은 다시 폼으로 돌아가서 하나하나 다시 작성해야한다.

웹 서비스는 폼 입력시 오류가 발생하면 고객이 입력한 데이터를 유지한 상태로 어떤 오류가 발생했는지 알려주어야 한다.

컨트롤러의 중요한 역할 중 하나는 HTTP 요청이 정상인지 검증하는 것이다

참고 (클라이언트 검증, 서버 검증)

클라이언트 검증은 조작할 수 있으므로 보안에 취약하다.
서버만으로 검증하면 즉각적인 고객 사용성이 부족해진다.
둘을 적절히 섞어 사용하되, 최종적으로 서버 검증은 필수이다.
API 방식을 사용한다면 API 스펙을 잘 정의해 검증 오류를 API 응답 결과에 잘 남겨주어야 한다.

검증 직접 처리 (스프링 X)

서버 검증 로직이 실패하면, 고객에게 다시 상품 등록 폼을 보여주고 값을 유지한 상태로 오류 메시지를 전달해줘야 한다.

상품 등록 검증

  
@PostMapping("/add")  
public String addItem(@ModelAttribute Item item, RedirectAttributes redirectAttributes, Model model) {  
  
	//검증 오류 결과를 보관  
	Map<String, String> errors = new HashMap<>();  
  
	//검증 로직  
	if (!StringUtils.hasText(item.getItemName())) {  
		errors.put("itemName", "상품 이름은 필수입니다.");  
	}  
  
	if (item.getPrice() == null || item.getPrice() < 1000 || item.getPrice() > 1000000) {  
		errors.put("price", "가격은 1,000 ~ 1,000,000 까지 허용합니다.");  
	}  
  
	if (item.getQuantity() == null || item.getQuantity() > 9999) {  
		errors.put("quantity", "수량은 최대 9,999 까지 허용됩니다.");  
	}  
  
	//특정 필드가 아닌 복합 룰 검증  
	if (item.getPrice() != null && item.getQuantity() != null) {  
		int resultPrice = item.getPrice() * item.getQuantity();  
		if (resultPrice < 10000) {  
			errors.put("globalError", "가격 * 수량의 합은 10,000원 이상이어야 합니다. 현재 값 = " + resultPrice);  
		}  
	}  
  
	//검증에 실패하면 다시 입력 폼으로  
	if (!errors.isEmpty()) {  
		log.info("errors={}", errors);  
		model.addAttribute("errors", errors);  
		return "validation/v1/addForm";  
	}  
  
	//성공 로직  
	Item savedItem = itemRepository.save(item);  
	redirectAttributes.addAttribute("itemId", savedItem.getId());  
	redirectAttributes.addAttribute("status", true);  
	return "redirect:/validation/v1/items/{itemId}";  
}

이렇게 하면 검증에 실패했을 때, 다시 상품 상세페이지를 가지 않고 등록폼을 보여주게 된다.

이 때, 입력된 값이 유지되는데 addItem을 GET 함수를 구성할 때 new Item()으로 빈 객체를 보냈는데 이 빈 객체에 담기고 뷰 템플릿의 th:field를 통해 그 값을 보여주도록 되어있기 때문이다.

화면에 오류 메시지를 띄우려면 아래와 같이 HTML에 코드를 추가해주면 된다.

  
<div th:if="${errors?.containsKey('globalError')}">  
	<p class="field-error" th:text="${errors['globalError']}"></p>  
</div>

스타일 태그에 클래스별로 설정해 문구의 색상 등을 바꾸어 줄 수도 있다.

참고

  
<input type="text" id="itemName" th:field="*{itemName}"  
th:class="${errors?.containsKey('itemName')} ? 'form-control field-error' : 'form-contorl'"  
class="form-control">

이런식으로 검증 실패 시 input 박스의 색상도 바꿀 수 있다.

Safe Navigation Operator

errors뒤에 ‘?’가 붙은 것을 볼 수 있다. 이는 errors가 null인 경우를 방지할 때 사용한다.

(errors?. 는 errors가 null일때 NullPointerException이 발생하는 대신 null을 반환한다. th:if 에서 null은 실패로 처리되므로 오류 메시지가 출력되지 않는다.)

POST가 아닌 처음 GET 등록폼에 진입한 시기라고 가정하자. errors는 당연히 처음엔 비어있다.

같은 HTML을 공유하고 있는데 errors에 containsKey를 호출하면 null.containsKey()와 마찬가지기 때문에 NullPointerException이 발생하게 된다.

남은 문제점

뷰 템플릿에서 중복 처리가 많다.
타입 오류 처리가 안된다. Item의 price, quantity 같은 숫자 필드는 타입이 Integer이므로 문자 타입으로 설정하는 것이 불가능하다.
- 하지만 이런 오류는 스프링 MVC에서 컨트롤러에서 진입하기도 전에 예외가 발생하기 때문에, 컨트롤러가 호출되지도 않고, 400 예외가 발생한다.
Item의 price에 문자를 입력하는 것 처럼 타입 오류가 발생해도 고객이 입력한 문자를 화면에 남겨야 한다.
- 만약 컨트롤러가 호출된다고 해도 Item의 price는 Integer이므로 문자를 보관할 수 없다.
- 문자는 바인딩이 불가능하므로 고객이 입력한 문자가 사라지고, 고객은 본인이 어떤 내용을 입력해 오류가 발생했는지 이해하기 어렵다.

결론적으로는 고객이 입력한 값도 어딘가에 별도로 관리되어야 한다.

검증 (스프링 사용)

스프링이 제공하는 검증 오류 처리 방법을 적용해본다.

핵심은 BindingResult이다.

BindingResult

  
@PostMapping("/add")  
public String addItem(@ModelAttribute Item item, BindingResult bindingResult, RedirectAttributes redirectAttributes, Model model) {  
  
	//검증 로직  
	if (!StringUtils.hasText(item.getItemName())) {  
		bindingResult.addError(new FieldError("item", "itemName", "상품 이름은 필수입니다."));  
	}  
  
	if (item.getPrice() == null || item.getPrice() < 1000 || item.getPrice() > 1000000) {  
		bindingResult.addError(new FieldError("item", "price", "가격은 1,000 ~ 1,000,000 까지 허용합니다."));  
	}  
  
	if (item.getQuantity() == null || item.getQuantity() > 9999) {  
		bindingResult.addError(new FieldError("item", "quantity", "수량은 최대 9,999 까지 허용됩니다."));  
	}  
  
	//특정 필드가 아닌 복합 룰 검증  
	if (item.getPrice() != null && item.getQuantity() != null) {  
		int resultPrice = item.getPrice() * item.getQuantity();  
		if (resultPrice < 10000) {  
			bindingResult.addError(new ObjectError("item", "가격 * 수량의 합은 10,000원 이상이어야 합니다. 현재 값 = " + resultPrice));  
		}  
	}  
  
	//검증에 실패하면 다시 입력 폼으로  
	if (bindingResult.hasErrors()) {  
		log.info("errors={}", bindingResult);  
		return "validation/v2/addForm";  
	}  
  
	//성공 로직  
	Item savedItem = itemRepository.save(item);  
	redirectAttributes.addAttribute("itemId", savedItem.getId());  
	redirectAttributes.addAttribute("status", true);  
	return "redirect:/validation/v2/items/{itemId}";  
}

BindingResult 파라미터의 위치는 @ModelAttribute Item item 다음에 와야한다.

오류를 Map을 생성해서 담았던 것을 BindingResult 객체에 담는다.
new FieldError() : 필드에 오류가 있으면 해당 객체를 생성해 담는다.
- 파라미터 설명
  - objectName (“item”) : @ModelAttribute 이름
  - field (“itemName”) : 오류가 발생한 필드 이름
  - defaultMessage : 오류 기본 메시지
new ObjectError() : 특정 필드를 넘어서는 오류가 있으면 여기에 담는다.
- 파라미터 설명
  - objectName (“item”) : @ModelAttribute 이름
  - defaultMessage : 오류 기본 메시지

위에서는 이러한 오류 메시지를 담았던 Map을 model에 추가해주었었는데 BindingResult를 사용하면 직접 해줄 필요 없다. 알아서 해준다.

HTML 에서의 접근

#fields.globalErrors()
- 글로벌에러가 하나가 아닐 수 있기 때문에 반복문으로 돌려준다.
- #fields로 BindingResult가 제공하는 검증 오류에 접근 가능.
th:errors
- if문으로 에러가 있는지 containsKey를 통해 확인했던 부분
- true면 th:text로 출력했던 부분.
- 위의 두가지를 한 줄로 알아서 해준다.
th:errorclass
- 해당 필드에 오류가 발생하면 field-error 클래스로 바꾸어준다.
- th:field에서 지정한 필드에 오류가 있으면 class 정보를 추가하는 것이다.

BindingResult 자세히

스프링이 제공하는 검증 오류를 보관하는 객체이다.
@ModelAttribute에 데이터 바인딩 오류가 발생해도 컨트롤러가 호출된다.
- 타입이 다른 값을 넣어도 400오류 X, 오류 메시지 출력됨.
사용 방법
- @ModelAttribute의 객체에 타입 오류 등으로 바인딩이 실패하는 경우 스프링이 FieldError를 생성해 BindingResult에 알아서 넣어준다.
- 개발자가 직접 넣어준다.
- Validator를 사용한다. (아래 설명)
BindingResult는 model에 자동으로 포함된다.
@ModelAttribute 바로 뒤 같이 검증할 대상 바로 다음에 와야한다.
- 순서가 중요하다.

참고

BindingResult는 인터페이스이고 Errors 인터페이스를 상속받고 있다.

실제 넘어오는 구현체는 BeanPropertyBindingResult라는 것인데 둘 다 구현하고 있으므로 BindingResult 대신 Errors를 사용해도 된다.

Errors 인터페이스는 단순한 오류 저장과 조회 기능을 제공하는 것이고, BindingResult는 여기에 더해 추가적인 기능을 제공한다. addError()도 BindingResult가 제공하는 것이다. 주로 관례상 BindingResult를 많이 사용한다.

FieldError, ObjectError

위에서는 검증 오류가 발생해도 사용자가 입력했던 값을 유지시키지 않는다.

위와 같이 매개변수를 추가해주면 된다.

FieldError의 생성자를 보자.

  
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)

objectName : 오류가 발생한 객체 이름
field : 오류 필드
rejectedValue : 사용자가 입력한 값 (거절된 값)
- item.getPrice() 사용.
bindingFailure : 타입 오류같은 바인딩 실패인지, 검증 실패인지 구분 값
- false 사용
codes : 메시지 코드
- null 사용
arguments : 메시지에서 사용하는 인자
- null 사용
defaultMessage : 기본 오류 메시지

ObjectError도 유사하게 두 가지 생성자를 제공한다.

그래서 입력값이 왜 유지되는가?

사용자의 입력 데이터가 컨트롤러의 @ModelAttribute에 바인딩되는 시점에 오류가 발생하면 모델 객체에 사용자 입력 값을 유지하기 어렵다.

예를 들면 가격에 숫자가 아닌 문자가 입력된다면 가격은 Integer 타입이므로 문자를 보관할 수 있는 방법이 없는 경우이다.

FieldError는 오류 발생 시 사용자 입력 값을 저장하는 기능을 제공한다.

위의 rejectedValue 가 오류 발생시 사용자 입력 값을 저장하는 필드이다. bindingFailure는 타입 오류 같은 바인딩이 실패했는지 여부를 적어주면 된다.

타임리프의 사용자 입력 값 유지

th:field 는 정상 상황에서는 모델 객체의 값을 사용하지만, 오류가 발생하면 FieldError에서 보관한 값을 사용해 값을 출력한다. 그래서 상황에 맞게 되는 것이다.

스프링의 바인딩 오류 처리

타입 오류로 바인딩에 실패하면 스프링은 FieldError를 생성하면서 사용자가 입력한 값을 넣어둔다. 그리고 해당 오류를 BindingResult에 담아 컨트롤러를 호출한다.

즉 FieldError의 생성과 그것을 담는 작업을 자동으로 해주는 것이다.

따라서 타입 오류 같은 바인딩 실패 시에도 사용자의 오류메시지를 정상 출력할 수 있다.

오류 코드와 메시지 처리

이전에는 오류 메시지를 FieldError를 생성할 때 하나하나 입력해주었는데 이러한 오류메시지도 서비스가 커지다보면 여러 곳에서 사용할 수 있고 이를 이전 포스트의 메시지 관리처럼 한곳에 모아 관리하면 유지보수가 편하다.

errors.properties 파일을 위와 같이 작성하고,

application.properties에 아래와 같이 작성한다.

spring.messages.basename=mesaages,errors

그리고 컨트롤러에서 FieldError를 생성할 때 codes와 args 매개변수를 사용해 이를 사용할 수 있다.

rejectValue(), reject() (v2)

FieldError, ObjectError는 다루기 좀 번거롭다는 생각이 들 수 있다.

컨트롤러에서 BindingResult는 검증해야 할 객체 바로 다음에 오기 때문에 이미 본인이 검증해야 할 객체인 target을 알고 있다.

BindingResult가 제공하는 rejectValue(), reject()를 사용하면 FieldError, ObjectError를 직접 생성하지 않고 깔끔하게 검증 오류를 다룰 수 있다.

field (“price”) : 오류 필드 명
errorCode (“range”) : 오류 코드
- messageResolver를 위한 코드
errorArgs (new Object[]) : 오류 메시지에서 중괄호 값을 치환하기 위한 값.
defaultMessage : 오류 메시지를 찾을 수 없을 때 사용하는 기본 메시지

그런데 errorCode 부분에 “range” 라고 적었다.

실제 errors에서는 “range.item.price” 이다. 어떻게 가능할까?

이러한 부분을 이해하기 위해서는 MessageCodesResolver를 이해해야 한다.

오류 코드를 만들 때 range.item.price 와 같이 자세히 만들 수 있고 range=범위오류입니다. 이런식으로 간단히 만들 수도 있다.

단순하게 만들면 범용성이 좋아 여러 곳에서 사용할 수 있다. 하지만 메시지를 세밀하게 작성하기 어렵다. 반대로 너무 자세하게 만들면 범용성이 떨어진다.

가장 좋은 방법은 범용성으로 사용하다가, 세밀하게 작성해야 하는 경우 세밀한 내용이 적용되도록 메시지에 단계를 두는 방법이다.

예시

required=필수 값 입니다.
required.item.itemName=상품 이름은 필수 입니다.

처음에는 required로만 관리했었는데, 기획의 변경 등으로 상품 이름은 필수 입니다. 라고 바꾸어야 된다고 가정하자.

컨트롤러에는 이미 rejectValue(“itemName”, “required”, null) 이런식으로 작성되어있다.

이럴 때 2번째 줄을 추가하게 되면 더 세부적인 부분이 우선시 되어 상품 이름은 필수 입니다. 가 되기 때문이다.

즉 객체명과 필드명을 조합한 세밀한 코드가 있으면 우선순위가 높은 것이다.

MessageCodesResolver?

테스트코드를 통해 MessageCodesResolver에 대해 본다.

검증 오류 코드로 메시지 코드들을 생성한다.
MessageCodesResolver 인터페이스이고 DefaultMessageCodesResolver는 기본 구현체이다.
주로 ObjectError, FieldError와 함께 사용한다.

기본 메시지 생성 규칙

//객체 오류의 경우
1.: code + "." + object name (required.item)
2.: code (required)

ex) 오류코드: required, object name: item

//필드 오류의 경우
1.: code + "." + object name + "." + field
2.: code + "." + field
3.: code + "." + field type
4.: code

동작 방식

rejectValue(), reject()는 내부에서 MessageCodesResolver를 사용한다. 여기서 메시지 코드들을 생성한다.
FieldError, ObjectError의 생성자를 보면 오류 코드를 하나가 아닌 여러개를 가질 수 있다. MessageCodesResolver를 통해 생성된 순서대로 오류 코드를 보관한다. (1번 발견하면 1번, 1번 발견 못하면 2번으로 넘어가는 방식)

이러한 과정 이후 타임리프 화면을 렌더링 할 때 th:errors가 실행될 때 오류가 있다면 생성된 오류 메시지 코드를 순서대로 돌아가며 메시지를 찾고 없을 때 디폴트 메시지를 출력하는 것이다.

스프링이 직접 만든 오류 메시지 처리

검증 오류 코드는 아래와 같은 2가지로 나눌 수 있다.

개발자가 직접 설정한 오류 코드 -> rejectValue()를 직접 호출
스프링이 직접 검증 오류에 추가한 경우 (주로 타입 정보 불일치)

price 필드에 문자를 입력해보자.

BindingResult에 FieldError가 담겨있고, 아래와 같은 메시지 코드들이 생성된다.

codes[typeMismatch.item.price, typeMismatch.price,
 typeMismatch.java.lang.Integer, typeMismatch]

스프링은 타입 오류가 발생하면 typeMismatch라는 오류 코드를 사용한다. 이 오류 코드가 MessageCodesResolver를 통하면서 4가지 메시지 코드가 생성된 것이다.

이대로 실행하면 스프링이 생성한 기본 메시지 (복잡한 메시지) 가 생성된다.

errors.properties에 아래와 같은 내용을 추가한다면?

typeMismatch.java.lang.Integer=숫자를 입력해주세요.
typeMismatch=타입 오류입니다.

소스코드를 하나도 건들지 않고 원하는 메시지를 단계별로 설정할 수 있다.

Validator 분리

이전에 다루었던 방법은 하나의 컨트롤러에서 검증 로직을 다 담당하고 있었다.

이러한 경우 검증 로직을 별도의 클래스가 담당하도록 해 역할을 분리시키는 것이 좋다. 이렇게 분리하면 재사용도 쉬워진다.

ItemValidator를 만들어본다.

  
@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) {  
		Item item = (Item) target;  
  
		ValidationUtils.rejectIfEmptyOrWhitespace(errors, "itemName",  "required");  
  
		if (item.getPrice() == null || 
			item.getPrice() < 1000 ||  
			item.getPrice() > 1000000) {  
				errors.rejectValue("price", "range", new Object[]{1000, 1000000},  null);  
		}  
		if (item.getQuantity() == null || item.getQuantity() > 10000) {  
			errors.rejectValue("quantity", "max", new Object[]{9999}, null);  
		}  
		//특정 필드 예외가 아닌 전체 예외  
		if (item.getPrice() != null && item.getQuantity() != null) {  
			int resultPrice = item.getPrice() * item.getQuantity();  
			if (resultPrice < 10000) {  
				errors.reject("totalPriceMin", new Object[]{10000,  resultPrice}, null);  
			}  
		}  
	}  
}

supports() : 해당 검증기를 지원하는 지 여부 확인
validate() : 검증 대상 객체와 BindingResult

컨트롤러에서의 사용을 보자.

  
@PostMapping("/add")  
public String addItemV5(@ModelAttribute Item item, BindingResult bindingResult, RedirectAttributes redirectAttributes, Model model) {  
  
	itemValidator.validate(item, bindingResult);  
  
	//검증에 실패하면 다시 입력 폼으로  
	if (bindingResult.hasErrors()) {  
		log.info("errors={}", bindingResult);  
		return "validation/v2/addForm";  
	}  
  
	//성공 로직  
	Item savedItem = itemRepository.save(item);  
	redirectAttributes.addAttribute("itemId", savedItem.getId());  
	redirectAttributes.addAttribute("status", true);  
	return "redirect:/validation/v2/items/{itemId}";  
}

검증로직을 한 줄로 해결 가능하다.

애노테이션 사용 (v2)

스프링이 Validator 인터페이스를 별도로 제공하는 이유는 체계적인 검증 기능을 도입하기 위함이다.

위에서는 검증기를 직접 불러 사용한 것이고, 실제로 이렇게 사용해도 된다.

하지만 Validator 인터페이스를 사용해 검증기를 만들면 스프링의 추가적인 도움을 받을 수 있다.

컨트롤러에 아래의 코드를 추가한다.

  
@InitBinder 
public void init(WebDataBinder dataBinder) {
 	log.info("init binder {}", dataBinder);
 	dataBinder.addValidators(itemValidator); 
}

이렇게 WebDataBinder에 검증기를 추가하면 해당 컨트롤러에서는 검증기를 자동으로 적용할 수 있다.

@InitBinder: 해당 컨트롤러에만 영향을 준다. (글로벌 설정은 따로 해줘야한다.)

실제로 사용은 아래와 같이 할 수 있다.

  
@PostMapping("/add") 
public String addItemV6(@Validated @ModelAttribute Item item, BindingResult bindingResult, RedirectAttributes redirectAttributes) { 
	if (bindingResult.hasErrors()) { 
		log.info("errors={}", bindingResult); 
		return "validation/v2/addForm"; 
	} 

	//성공 로직 
	Item savedItem = itemRepository.save(item); 
	redirectAttributes.addAttribute("itemId", savedItem.getId()); 
	redirectAttributes.addAttribute("status", true); return 
	"redirect:/validation/v2/items/{itemId}"; 
}

validator를 직접 호출하는 부분이 사라지고, 대신 검증 대상 앞에 @Validated가 붙는다.

동작 방식

@Validated는 검증기를 실행하라는 애노테이션이다.

이 애노테이션이 붙으면 앞서 WebDataBinder에 등록한 검증기를 찾아 실행한다. 그런데 여러 검증기를 등록한다면 그 중 어떤 검증기가 실행되어야 할 지 구분이 필요하다.

이 때 supports() 가 사용된다.

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

supports(Item.class)가 호출되고, 결과가 true이므로 ItemValidator의 validate()가 호출되는 것이다.

글로벌 설정

  
@SpringbootApplication 부분에 추가

@Override
public Validator getValidator() {
	return new ItemValidator();
}

이런식으로 각 컨트롤러에 @InitBinder를 사용하지 않고 글로벌 설정을 추가할 수 있지만 실제로는 글로벌 설정을 직접 사용하는 경우는 드물다.