[SpringBoot] 서버에서 사용자 입력 값과 Request Body를 Validation하는 2가지 방법

📌 Validation이 필요한 이유

의도적으로 이상한 값으로 서버에 요청을 보낼 수 있기 때문에 프론트와 서버에서 둘다 해줘야 한다.

회사 코드를 보니 이메일이나 전화번호 입력 값에 대한 형식을 모두 서버에서도 체크해주었다.

(기존에 사이드 프로젝트 할 때는 '입력값은 프론트에서 유효성 검사 해주니까 괜찮겠지' 하고 넘어갔었는데 반성하게 되었다. 다음 사이드 프로젝트에서는 입력값에 대한 서버 유효성 검사도 추가해야겠다)

 

그렇다면, 어차피 서버에서도 유효성 검사를 해주는데 프론트에서도 하는 이유는?

- 서버 부하를 줄여주고, 사용자의 편의성을 위해서이다.

- 서버에서의 유효성 검사는 프론트에서의 유효성 검사보다는 느릴 수 밖에 없다.

 

📌 준비

• 의존성 추가

dependencies {
	implementation 'org.springframework.boot:spring-boot-starter-validation'
}

위의 의존성을 추가하면, Bean Validation 구현체로 Hibernate Validator를 사용하여 Spring Boot에서 Validation을 쉽게 사용할 수 있다.

 

📌 방법1 - Hibernate에서 제공하는 javax.validation.constraints(@NotEmpty, @NotNull 등)의 기존 구현된 어노테이션 사용

@Getter
@Setter
@NoArgsConstructor
    publicclass UserSignUpReqDto {
				...

        @NotEmpty(message = "닉네임은 필수입니다.")
        private String nickName;    //닉네임

        @NotEmpty(message = "이메일은 필수입니다.")
        @Email
        private String email;   //이메일

	      ...
    }

 

위와 같이 구현되어 있는 어노테이션을 사용해 적용이 가능하다.

 

@NotEmpty, @NotNull, @NotBlank의 차이는?

• @NotEmpty - null, ""을 허용하지 않는다. " "는 허용한다.
• @NotNull - null만 허용하지 않는다. "", " "는 허용한다.
• @NotBlank - null, "", " "을 모두 허용하지 않는다.

 

📌 방법2 - ConstraintValidator 인터페이스를 사용해 Custom Validation 구현

Custom Validation 사용 이유

• 사용자 입력 값의 유효성을 세부적으로 검사해야할 때 사용한다.
• 예외 검증 로직을 생성해두어 반복코드를 줄이고, 어노테이션으로 간결하게 적용이 가능하다.

 

주의할 점

• 어노테이션의 내부 로직이 어떤 동작을 하는지 정확히 모른다면, 플로우를 이해하기 어렵다.
• 반복적으로 사용하지 않고, 특정 요청에만 사용하는 유효성 검사의 경우에는 이것 대신 단순 메서드로 처리하는게 좋다.

 

구현 방법

• 기존에 구현되어있는 @NotEmpty나 @NotNull과 동일한 방식으로 구현하면 된다.
• 추가해야할 파일은 커스텀 어노테이션 interface와 ConstraintValidator 인터페이스를 구현한 커스텀 Validator 클래스 총 2가지 이다.

 

실습

회원가입 정보 입력 시 전화번호와 비밀번호 형식을 체크해주는 custom validator를 구현해보았다.

 

👩🏻‍💻 실습 코드 확인 : spring-validation-practice

 

A. 커스텀 어노테이션 interface

// SignUpDtoCheck interface
@Constraint(validatedBy = SignUpDtoCheckValidator.class)
@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
public @interface SignUpDtoCheck {

    String message() default "SignUpDtoCheck is invalid";

    Class<?>[] groups() default { };

    Class<? extends Payload>[] payload() default { };
}

• @Constraint
  • validatedBy의 값에 ConstraintValidator 인터페이스를 구현한 커스텀 Validator 클래스를 지정해준다. 실질적인 검증이 이뤄지는 클래스이다.

• @Target
  • 해당 어노테이션이 적용될 수 있는 타입을 지정하는 것이다.
  • ElementType.TYPE의 경우 클래스, 인터페이스, Enum에 적용 가능하다.

• @Retention
  • 해당 어노테이션의 라이프 사이클을 지정하는 것이다.

• @interface
  • 어노테이션으로 사용 가능한 인터페이스를 의미한다.

 

B. ConstraintValidator 인터페이스를 구현한 커스텀 Validator 클래스

public class SignUpDtoCheckValidator implements ConstraintValidator<SignUpDtoCheck, UserDto.UserSignUpReqDto> {

    @Override
    public void initialize(SignUpDtoCheck constraintAnnotation) {

    }

    @Override
    public boolean isValid(UserDto.UserSignUpReqDto value, ConstraintValidatorContext context) {

        int invalidCount = 0;

        PatternUtils patternUtils = new PatternUtils();

        if(!patternUtils.phoneNumberMatch(value.getPhoneNumber())) {
            addConstraintViolation(context, "전화번호는 숫자 8~11자만 가능합니다.", "phoneNumber");
            invalidCount++;
        }

        if (!patternUtils.passwordMatch(value.getPassword())) {
            addConstraintViolation(context, "비밀번호는 영문자 4~6자만 가능합니다.", "password");
            invalidCount++;
        }

        return invalidCount == 0;
    }

    private void addConstraintViolation(ConstraintValidatorContext context, String errorMessage, String firstNode) {
        context.disableDefaultConstraintViolation()
        context.buildConstraintViolationWithTemplate(errorMessage)
                .addPropertyNode(firstNode)
                .addConstraintViolation();
    }

}

• ConstraintValidator 인터페이스를 구현하기 위해서는 initialize()와 isValid() 메서드를 오버라이딩 해줘야 한다.

• isValid() 내부에 검증 로직을 구현하여 boolean으로 값을 반환해준다.

• addConstraintViolation()
  • disableDefaultConstraintViolation() - SignUpDtoCheck 인터페이스에 설정해둔 default message 대신 다른 내용을 사용하도록 한다.
  • 구체적인 에러 메시지와 검증한 Node Key값을 넘겨준다. 해당 Node는 Errors 객체의 errors 리스트에 저장될 원소의 field 속성에 바인딩된다.

 

C. Validation 적용

@Getter @Setter
@NoArgsConstructor
@SignUpDtoCheck //어노테이션을 사용해 적용
public static class UserSignUpReqDto {

        @NotEmpty(message = "닉네임은 필수입니다.")
        private String nickName;    //닉네임

        private String phoneNumber; //전화번호

        @NotEmpty(message = "이메일은 필수입니다.")
        @Email
        private String email;   //이메일

        private String password;    //비밀번호

        @Builder
        public UserSignUpReqDto(String nickName, String phoneNumber, String email, String password) {
            this.nickName = nickName;
            this.phoneNumber = phoneNumber;
            this.email = email;
            this.password = password;
        }
 }

//Controller
@PostMapping("/user/sign-up")
public String userSignUp(@Valid UserDto.UserSignUpReqDto userSignUpReqDto, Errors errors, Model model) {
        //회원가입 실패
        if (errors.hasErrors()) {

            return "user/sign-up";
        }

        //회원가입 성공 (로그인 완료 페이지로 리다이렉션)
        return "user/login";
}

 

🎈 참고

• https://tecoble.techcourse.co.kr/post/2021-06-21-custom-annotation/
• https://cheese10yun.github.io/ConstraintValidator/

 

📌 위의 방법1과 방법2을 모두 사용하는 경우에 대한 주의사항

만약 동일한 필드에 @NotNull과 Validator 클래스를 직접 구현한 방식을 모두 적용하였다면, @NotNull과 직접 구현한 Validator를 모두 거치게 된다.

@NotNull에서 체크가 되었다고 구현한 Validator 클래스의 isValid()를 안거치는 것이 아니라 무조건 둘다 거치게 된다.

이때 적절한 if문 조건 처리를 하지 않는다면, null 값이 들어왔을 때 동일한 필드에 대해 2개의 error가 반환된다. 

 

따라서 아예 Validator 클래스에서만 유효성 검사를 하게 하든지, 혹은 Validator 클래스 내부의 if문에 조건을 잘 정의해줘야 한다. (이것을 간과하고 오류가 2개 나온다는 것을 좀 지나서야 알게 되었다..^^)

 

▶️ 예시 코드

//@NotBlank를 설정해줬을 때
public class sampleDto {
	...
	@NotBlank
	private String email;
	...
}

//전달된 값이 blank나 null이 아닌 경우에만 유효성 검사 수행
public class sampleValidator implements ConstraintValidator<...> {

	@Override
	public boolean isValid(...) {
		...
		if (!StringUtils.isBlank(value.getEmail()) && !validationUtils.emailMatch(value.getEmail())) {
            addConstraintViolation(context, "이메일 형식으로 입력해주세요.", "email");
            invalidCount++;
    }
	}
}

위와 같은 예시 상황에서 만약 @NotBlank로 설정해줬다면, 커스텀 Validator 클래스에서는 blank나 null이 아닌 경우에만 유효성 검사를 추가로 수행하도록 하는 것이다.