Validation

검증

서버 VS 클라이언트

• 클라이언트 검증은 조작 가능 → 보안 취약

• 서버만으로 검증하면, 즉각적인 고객 사용성이 떨어진다.

• 둘을 섞어 사용, 최종적으로 서버 검증은 필수

• API 방식을 사용하면, API 스펙을 잘 정의해서 검증 오류를 API 응답 결과에 잘 남겨주어야 함

시나리오

• 검증에 성공할 경우

• 검증에 실패할 경우
• 만약 검증 오류가 발생하면 입력 폼을 다시 보여준다.
• 검증 오류들을 고객에게 친절하게 안내해서 다시 입력할 수 있게 한다.
• 검증 오류가 발생해도 고객이 입력한 데이터가 유지된다.

Thymeleaf

Safe Navigation Operator

필드 오류 처리

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

남은 문제점

• 타입 오류 처리가 안된다. Item 의 price , quantity 같은 숫자 필드는 타입이 Integer 이므로 문자 타입으로 설정하는 것이 불가능하다. 숫자 타입에 문자가 들어오면 오류가 발생한다. 그런데 이러한 오류는 스프링MVC에서 컨트롤러에 진입하기도 전에 예외가 발생하기 때문에, 컨트롤러가 호출되지도 않고, 400 예외가 발생하면서 오류 페이지를 띄워준다.

• Item의 price에 문자를 입력하는 것 처럼 타입 오류가 발생해도 고객이 입력한 문자를 화면에 남겨야한다. 만약 컨트롤러가 호출된다고 가정해도 Item 의 price 는 Integer 이므로 문자를 보관할 수가 없다. 결국 문자는 바인딩이 불가능하므로 고객이 입력한 문자가 사라지게 되고, 고객은 본인이 어떤 내용을 입력해서 오류가 발생했는지 이해하기 어렵다. 결국 고객이 입력한 값도 어딘가에 별도로 관리가 되어야 한다.

BindingResult

Spring이 제공하는 검증 오류 보관 객체

• BindingResult 가 있으면 @ModelAttribute 에 데이터 바인딩 시 오류가 발생해도 컨트롤러가 호출된다!

예시

@ModelAttribute에 바인딩 시 타입 오류가 발생하면?

• BindingResult 가 없으면, 400 오류가 발생하면서 컨트롤러가 호출되지 않고, 오류 페이지로 이동한다.

• BindingResult 가 있으면, 오류 정보( FieldError )를 BindingResult 에 담아서 컨트롤러를 정상 호출한다.

주의

필드 오류 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)

• 필드에 오류가 있으면 FieldError 객체를 생성해서 bindingResult 에 담아두면 된다.
• objectName : @ModelAttribute 이름
• field : 오류가 발생한 필드 이름
• rejectecValue: 사용자가 입력한 값(거절된 값)
• bindingFailure: 타입 오류 같은 바인딩 실패인지, 검증 실패인지 구분 값
• codes: 메시지 코드
• arguments: 메시지에서 사용하는 인자
• defaultMessage : 오류 기본 메시지

오류 발생시 사용자 입력 값 유지

Thymeleaf의 사용자 입력 값 유지

스프링의 바인딩 오류 처리

글로벌 오류 ObjectError 생성자

public ObjectError(String objectName, String defaultMessage) {}

• objectName : @ModelAttribute 의 이름

• defaultMessage : 오류 기본 메시지

Thymeleaf Spring 검증 오류 통합 기능

• #fields : #fields 로 BindingResult 가 제공하는 검증 오류에 접근할 수 있다.

• th:errors : 해당 필드에 오류가 있는 경우에 태그를 출력한다. th:if 의 편의 버전이다.

• th:errorclass : th:field 에서 지정한 필드에 오류가 있으면 class 정보를 추가한다.

• 검증과 오류 메시지 공식 메뉴얼

글로벌 오류 처리

<div th:if="${#fields.hasGlobalErrors()}">
      <p class="field-error" th:each="err : ${#fields.globalErrors()}" th:text="${err}">전체 오류 메시지</p> 
</div>

필드 오류 처리

<input type="text" id="itemName" th:field="*{itemName}" th:errorclass="field-error" class="form-control" placeholder="이름을 입력하세요">
<div class="field-error" th:errors="*{itemName}">
	상품명 오류
</div>

오류 코드와 메시지 처리

FieldError, ObjectError는 codes, arguments를 통해 오류 발생시 오류 코드로 오류 메시지를 체계적으로 다룰 수 있다.

errors 메시지 파일 생성

Spring Boot 메시지 설정 추가

spring.messages.basename=messages,errors

errors.properties 추가

required.item.itemName=상품 이름은 필수입니다. 
range.item.price=가격은 {0} ~ {1} 까지 허용합니다. 
max.item.quantity=수량은 최대 {0} 까지 허용합니다. 
totalPriceMin=가격 * 수량의 합은 {0}원 이상이어야 합니다. 현재 값 = {1}

참고

Controller

• codes : required.item.itemName 를 사용해서 메시지 코드를 지정한다. 메시지 코드는 하나가 아니라 배열로 여러 값을 전달할 수 있는데, 순서대로 매칭해서 처음 매칭되는 메시지가 사용된다.

• arguments : Object[]{1000, 1000000} 를 사용해서 코드의 {0} , {1} 로 치환할 값을 전달한다.

rejectValue() , reject()

@PostMapping("/add")
  public String addItemV4(@ModelAttribute Item item, BindingResult bindingResult, RedirectAttributes redirectAttributes) {
      log.info("objectName={}", bindingResult.getObjectName());
      log.info("target={}", bindingResult.getTarget());

      if (!StringUtils.hasText(item.getItemName())) {
          bindingResult.rejectValue("itemName", "required");
			}
      if (item.getPrice() == null || item.getPrice() < 1000 || item.getPrice() > 1000000) {
          bindingResult.rejectValue("price", "range", new Object[]{1000, 1000000}, null);
      }
      if (item.getQuantity() == null || item.getQuantity() > 10000) {
          bindingResult.rejectValue("quantity", "max", new Object[]{9999}, null);
      }

			//특정 필드 예외가 아닌 전체 예외
			if (item.getPrice() != null && item.getQuantity() != null) {
          int resultPrice = item.getPrice() * item.getQuantity();
          if (resultPrice < 10000) {
              bindingResult.reject("totalPriceMin", new Object[]{10000, resultPrice}, null);
					}
			}
...

rejectValue()

void rejectValue(@Nullable String field, String errorCode, @Nullable Object[] errorArgs, @Nullable String defaultMessage);

• field : 오류 필드명

• errorCode : 오류 코드(이 오류 코드는 메시지에 등록된 코드가 아니다. 뒤에서 설명할 messageResolver를 위한 오류 코드이다.)

• errorArgs : 오류 메시지에서 {0} 을 치환하기 위한 값

• defaultMessage : 오류 메시지를 찾을 수 없을 때 사용하는 기본 메시지

bindingResult.rejectValue("price", "range", new Object[]{1000, 1000000}, null)

range.item.price=가격은 {0} ~ {1} 까지 허용합니다.

reject()

void reject(String errorCode, @Nullable Object[] errorArgs, @Nullable String defaultMessage);

오류 코드 만들기

• required.item.itemName : 상품 이름은 필수 입니다.

• range.item.price : 상품의 가격 범위 오류 입니다.

• required : 필수 값 입니다.

• range : 범위 오류 입니다.

required: 필수 값 입니다.

#Level1
required.item.itemName: 상품 이름은 필수 입니다. 

#Level2
required: 필수 값 입니다.

MessageCodesResolver

• 검증 오류 코드로 메시지 코드들을 생성한다.

• MessageCodesResolver 인터페이스이고 DefaultMessageCodesResolver 는 기본 구현체이다.

• 주로 다음과 함께 사용 ObjectError , FieldError

DefaultMessageCodesResolver의 기본 메시지 생성 규칙

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

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

필드 오류의 경우 다음 순서로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 를 사용한다. 여기에서 메시지 코드들을 생성한다.

• FieldError , ObjectError 의 생성자를 보면, 오류 코드를 하나가 아니라 여러 오류 코드를 가질 수 있다. MessageCodesResolver 를 통해서 생성된 순서대로 오류 코드를 보관한다.

• 이 부분을 BindingResult 의 로그를 통해서 확인해보자.

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

• required.item.itemName

• required.itemName

• required.java.lang.String

• required

• totalPriceMin.item

• totalPriceMin

오류 코드 관리 전략

핵심은 구체적인 것에서! 덜 구체적인 것으로!

왜 이렇게 복잡하게 사용하는가?

오류 코드 전략 도입

#required.item.itemName=상품 이름은 필수입니다. 
#range.item.price=가격은 {0} ~ {1} 까지 허용합니다. 
#max.item.quantity=수량은 최대 {0} 까지 허용합니다. 
#totalPriceMin=가격 * 수량의 합은 {0}원 이상이어야 합니다. 현재 값 = {1}

#==ObjectError==
#Level1
totalPriceMin.item=상품의 가격 * 수량의 합은 {0}원 이상이어야 합니다. 현재 값 = {1}

#Level2 - 생략
totalPriceMin=전체 가격은 {0}원 이상이어야 합니다. 현재 값 = {1}

#==FieldError==
#Level1
required.item.itemName=상품 이름은 필수입니다. 
range.item.price=가격은 {0} ~ {1} 까지 허용합니다. 
max.item.quantity=수량은 최대 {0} 까지 허용합니다.

#Level2 - 생략

#Level3
required.java.lang.String = 필수 문자입니다. 
required.java.lang.Integer = 필수 숫자입니다. 
min.java.lang.String = {0} 이상의 문자를 입력해주세요. 
min.java.lang.Integer = {0} 이상의 숫자를 입력해주세요. 
range.java.lang.String = {0} ~ {1} 까지의 문자를 입력해주세요. 
range.java.lang.Integer = {0} ~ {1} 까지의 숫자를 입력해주세요. 
max.java.lang.String = {0} 까지의 문자를 허용합니다. 
max.java.lang.Integer = {0} 까지의 숫자를 허용합니다.

#Level4
required = 필수 값 입니다.
min= {0} 이상이어야 합니다.
range= {0} ~ {1} 범위를 허용합니다. 
max= {0} 까지 허용합니다.

1. required.item.itemName

2. required.itemName

3. required.java.lang.String

4. required

ValidationUtils

ValidationUtils.rejectIfEmptyOrWhitespace(bindingResult, "itemName", "required");

정리

1. rejectValue() 호출

2. MessageCodesResolver 를 사용해서 검증 오류 코드로 메시지 코드들을 생성

3. new FieldError() 를 생성하면서 메시지 코드들을 보관

4. th:errors 에서 메시지 코드들로 메시지를 순서대로 메시지에서 찾고, 노출

Spring이 직접 만든 오류 메시지 처리

• 개발자가 직접 설정한 오류 코드 → rejectValue() 를 직접 호출

• 스프링이 직접 검증 오류에 추가한 경우(주로 타입 정보가 맞지 않음)

지금까지 학습한 메시지 코드 전략의 강점을 확인해보자

• typeMismatch.item.price

• typeMismatch.price

• typeMismatch.java.lang.Integer

• typeMismatch

error.properties 에 다음 내용을 추가하자

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

정리

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

• 메시지 코드 생성 전략은 그냥 만들어진 것이 아니다. 조금 뒤에서 Bean Validation을 학습하면 그 진가를 더 확인할 수 있다.

Validator 분리

복잡한 검증 로직을 별도로 분리하자.

ItemValidator

package hello.itemservice.web.validation;

import hello.itemservice.domain.item.Item;
import org.springframework.stereotype.Component;
import org.springframework.util.StringUtils;
import org.springframework.validation.Errors;
import org.springframework.validation.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) {
        Item item = (Item) target;

        if (!StringUtils.hasText(item.getItemName())) {
            errors.rejectValue("itemName", "required");
        }
        if (item.getPrice() == null || item.getPrice() < 1000 || item.getPrice() > 1000000) {
            errors.rejectValue("price", "range", new Object[]{1000, 10000000}, null);
        }
        if (item.getQuantity() == null || item.getQuantity() >= 9999) {
            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);
            }
        }
    }
}

Spring은 검증을 체계적으로 제공하기 위해 다음 인터페이스를 제공한다.

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

• supports() {} : 해당 검증기를 지원하는 여부 확인(뒤에서 설명)

• validate(Object target, Errors errors) : 검증 대상 객체와 BindingResult

ItemValidator 직접 호출

//Spring Bean으로 주입 받아 직접 호출
private final ItemValidator itemValidator;

...

@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}";
    }

WebDataBinder를 통해서 사용하기

Controller

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

@Validated 적용

@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}";
}

코드 변경

동작 방식

@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) {
		...
		}
}

@SpringBootApplication
public class ItemServiceApplication implements WebMvcConfigurer {
		public static void main(String[] args) {
		    SpringApplication.run(ItemServiceApplication.class, args);
		}

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

주의

@Validated VS @Valid

Bean Validation

특정한 구현체가 아닌 Bean Validation 2.0(JSR-380)이라는 기술 표준

목적

특징

하이버네이트 Validator 관련 링크

의존관계

implementation 'org.springframework.boot:spring-boot-starter-validation'

검증 애노테이션

참고

Bean Validation - Spring 통합

스프링 MVC는 어떻게 Bean Validator를 사용?

스프링 부트는 자동으로 글로벌 Validator로 등록한다.

주의!

검증 순서

1. @ModelAttribute 각각의 필드에 타입 변환 시도
1. 성공하면 다음으로
2. 실패하면 typeMismatch 로 FieldError 추가

2. Validator 적용

바인딩에 성공한 필드만 Bean Validation 적용

에러 코드

• @NotBlank
• NotBlank.item.itemName
• NotBlank.itemName
• NotBlank.java.lang.String
• NotBlank

• @Range
• Range.item.price
• Range.price
• Range.java.lang.Integer
• Range

메시지 등록

#Bean Validation 추가 
NotBlank={0} 공백X 
Range={0}, {2} ~ {1} 허용 
Max={0}, 최대 {1}

메시지 찾는 순서

1. 생성된 메시지 코드 순서대로 messageSource 에서 메시지 찾기

2. 애노테이션의 message 속성 사용 → @NotBlank(message = "공백! {0}")

3. 라이브러리가 제공하는 기본 값 사용 → 공백일 수 없습니다.

애노테이션의 message 예시

@NotBlank(message = "공백은 입력할 수 없습니다.") 
private String itemName;

오브젝트 오류

@Data
@ScriptAssert(lang = "javascript", script = "_this.price * _this.quantity >= 10000")
public class Item {
...
}

메시지 코드

• ScriptAssert.item

• ScriptAssert

한계

등록시 기존 요구사항

• 타입 검증
• 가격, 수량에 문자가 들어가면 검증 오류 처리

• 필드 검증
• 상품명: 필수, 공백X
• 가격: 1000원 이상, 1백만원 이하
• 수량: 최대 9999

• 특정 필드의 범위를 넘어서는 검증
• 가격 * 수량의 합은 10,000원 이상

수정시 요구사항

• 등록시에는 quantity 수량을 최대 9999까지 등록할 수 있지만 수정시에는 수량을 무제한으로 변경할 수 있다.

• 등록시에는 id 에 값이 없어도 되지만, 수정시에는 id 값이 필수이다.

수정은 잘 동작하지만 등록에서 문제가 발생한다.

Groups

방법 2가지

1. BeanValidation의 groups 기능을 사용한다.

2. Item을 직접 사용하지 않고, ItemSaveForm, ItemUpdateForm 같은 폼 전송을 위한 별도의 모델 객체를 만들어서 사용한다.

저장용 groups 생성

package hello.itemservice.domain.item;

public interface SaveCheck {
}

수정용 groups 생성

package hello.itemservice.domain.item;

public interface UpdateCheck {
}

Item - groups 적용

package hello.itemservice.domain.item;

import lombok.Data;
import org.hibernate.validator.constraints.Range;
import javax.validation.constraints.Max;
import javax.validation.constraints.NotBlank;
import javax.validation.constraints.NotNull;

@Data
  public class Item {
	@NotNull(groups = UpdateCheck.class) //수정시에만 적용 
	private Long id;

  @NotBlank(groups = {SaveCheck.class, UpdateCheck.class})
  private String itemName;

  @NotNull(groups = {SaveCheck.class, UpdateCheck.class})
  @Range(min = 1000, max = 1000000, groups = {SaveCheck.class, UpdateCheck.class})
  private Integer price;

  @NotNull(groups = {SaveCheck.class, UpdateCheck.class})
	@Max(value = 9999, groups = SaveCheck.class) //등록시에만 적용 
	private Integer quantity;

  public Item() {
  }

  public Item(String itemName, Integer price, Integer quantity) {
      this.itemName = itemName;
      this.price = price;
      this.quantity = quantity;
	} 
}

ValidationItemControllerV3 - 저장 로직에 SaveCheck Groups 적용

@PostMapping("/add")
public String addItemV2(@Validated(SaveCheck.class) @ModelAttribute Item item, BindingResult bindingResult, RedirectAttributes redirectAttributes) {
		...
}

ValidationItemControllerV3 - 수정 로직에 UpdateCheck Groups 적용

@PostMapping("/{itemId}/edit")
public String editV2(@PathVariable Long itemId, @Validated(UpdateCheck.class) @ModelAttribute Item item, BindingResult bindingResult) {
	...
}

정리

Form 전송 객체 분리

폼 데이터 전달에 별도의 객체 사용

• 장점: 전송하는 폼 데이터가 복잡해도 거기에 맞춘 별도의 폼 객체를 사용해서 데이터를 전달 받을 수 있다. 보통 등록과, 수정용으로 별도의 폼 객체를 만들기 때문에 검증이 중복되지 않는다.

• 단점: 폼 데이터를 기반으로 컨트롤러에서 Item 객체를 생성하는 변환 과정이 추가된다.

개발

폼 객체 바인딩

@PostMapping("/add")
public String addItem(@Validated @ModelAttribute("item") ItemSaveForm form, BindingResult bindingResult, RedirectAttributes redirectAttributes) {
		...
}

주의

폼 객체를 Item으로 변환

//성공 로직
Item item = new Item(); 
item.setItemName(form.getItemName()); 
item.setPrice(form.getPrice()); 
item.setQuantity(form.getQuantity());

Item savedItem = itemRepository.save(item);

수정

@PostMapping("/{itemId}/edit")
public String edit(@PathVariable Long itemId, @Validated @ModelAttribute("item") ItemUpdateForm form, BindingResult bindingResult) {
		...
}

HTTP 메시지 컨버터

ValidationItemApiController 생성

package hello.itemservice.web.validation;

import hello.itemservice.web.validation.form.ItemSaveForm;
import lombok.extern.slf4j.Slf4j;
import org.springframework.validation.BindingResult;
import org.springframework.validation.annotation.Validated;
import org.springframework.web.bind.annotation.*;

@Slf4j
@RestController
@RequestMapping("/validation/api/items")
public class ValidationItemApiController {

    @PostMapping("/add")
    public Object addItem(@RequestBody @Validated ItemSaveForm form, BindingResult bindingResult) {

        log.info("API 컨트롤러 호출");

        if (bindingResult.hasErrors()) {
            log.info("검증 오류 발생 errors={}", bindingResult);
            return bindingResult.getAllErrors();
        }

        log.info("성공 로직 실행");
        return form;
    }
}

성공 요청

POST http://localhost:8080/validation/api/items/add
{"itemName":"hello", "price":1000, "quantity": 10}

API의 경우 3가지 경우를 나누어 생각해야 한다.

• 성공 요청: 성공

• 실패 요청: JSON을 객체로 생성하는 것 자체가 실패함

• 검증 오류 요청: JSON을 객체로 생성하는 것은 성공했고, 검증에서 실패함

실패 요청

POST http://localhost:8080/validation/api/items/add
{"itemName":"hello", "price":"A", "quantity": 10}

실패 요청 결과

{
      "timestamp": "2021-04-20T00:00:00.000+00:00",
      "status": 400,
      "error": "Bad Request",
      "message": "",
      "path": "/validation/api/items/add"
}

검증 오류 요청

POST http://localhost:8080/validation/api/items/add
{"itemName":"hello", "price":1000, "quantity": 10000}

검증 오류 결과

[
		{
		"codes": [
		    "Max.itemSaveForm.quantity",
		    "Max.quantity",
		    "Max.java.lang.Integer",
		    "Max"
		],
		"arguments": 
		[
				{
						"codes": 
								[
						            "itemSaveForm.quantity", "quantity"
					      ],
					  "arguments": null,
					  "defaultMessage": "quantity",
					  "code": "quantity"
				},
				9999
		],
		"defaultMessage": "9999 이하여야 합니다",
		"objectName": "itemSaveForm",
		"field": "quantity",
		"rejectedValue": 10000,
		"bindingFailure": false,
		"code": "Max"
		} 
]

@ModelAttribute vs @RequestBody

• @ModelAttribute 는 필드 단위로 정교하게 바인딩이 적용된다. 특정 필드가 바인딩 되지 않아도 나머지 필드는 정상 바인딩 되고, Validator를 사용한 검증도 적용할 수 있다.

• @RequestBody 는 HttpMessageConverter 단계에서 JSON 데이터를 객체로 변경하지 못하면 이후 단계 자체가 진행되지 않고 예외가 발생한다. 컨트롤러도 호출되지 않고, Validator도 적용할 수 없다.

참고