쿠키 서버에서 로그인에 성공하면 HTTP 응답에 쿠키를 담아서 브라우저에 전달. -> 앞으로 브라우저는 서버로 요청 할 때마다 해당 쿠키를 계속 전달한다. -> 서버로 로그인 했다는 것을 알려준다. -> 로그인 상태를 유지하기 위함이다. 영속 쿠키 만료 날짜를 입력하면 해당 날짜까지 유지 세션 쿠키 만료 날짜를 생략하면 브라우저 종료시 까지 유지 로그인 기능을 개발해보자 위 예시는 쿠키를 만들어 응답으로 내려주는 예시이다. 만료 날짜를 생략 했기 때문에 세션 쿠키이다. 로그인 성공 시.. HttpServletResponse에 addCookie 메서드를 통하여 key, value 형태로 이루어진 Cookie를 추가하였다. -> 쿠키를 받은 클라이언트는 요청때 마다 쿠키를 보낼 것이다. 로그인 실패 시.. ..

지금까지는 클라이언트에서 HTML Form POST 형식 또는 HTTP 쿼리파라미터 GET 방식를 통한 요청에 대한 검증 방법론에 대하여 알아봤다. Bean Validation (LocalValidatorFactorBean) 방법은 HttpMessageConverter에도 적용할 수 있다. 정확하게는 .. @Valid, @Validated 는 HttpMessageConverter(@RequestBody)에도 적용할 수 있다. 이전 포스팅에서 알 수 있지만, @ModelAttribute는 HTTP 요청 파라미터(URL 쿼리, POST Form)를 다룰 때 사용한다. 하지만, HTTP Message Body 데이터를 객체로 변환할 때는 @RequestBody를 사용해야 한다.(주로 Json) 코드로 더 자세..

Validation 8에서 정말 간편한.. 스프링이 지원하는 글로벌 Validator(LocalValidatorFactorBean) 사용법을 알아봤다.. 추가로 개발 시, 고려 되어야 할 사항에 대해 알아보자. 여러 페이지에 대한 컨트롤러를 개발하다보면.. 비슷한 필드가 존재하는 HTML Form이 사용될 수 있다. 그래서 개발자는 여러페이지에 대해 동일하게 Binding할 객체를 하나만 생성해서 쓰려고 고려를 할 수 있다. (그래서 같은 객체를 사용) 이는.. 잘못된 접근이다.. 각 페이지에 대해 개발을 지속적으로 진행하다보면.. 예를들면.. 사양이 처음보다 많이 바뀌어 A페이지에서는 X객체의 a필드 값 범위가 1~100이고 B페이지에서는 X객체의 a필드 값 범위가 없다고 치면.. 하나의 객체의 하나의..

Validation 7번까지는 검증을 위해.. 아직도 코드를 쳐야할게 많아보인다.. 더 줄여보자.. 그리고 검증하는 로직이 ... 개발자 대부분이 다 사용할 거 같은 검증 로직이다.. (min max 지정, null인지 체크하는 로직 등) Bean Validator 하나의 기술표준이다. (JSR-380) (단순히 하나의 인터페이스나 구현체가 아님, 검증 어노테이션과 여러 인터페이스의 모음) 스프링 부트가 spring-boot-starter-validation 라이브러리를 넣으면 자동으로 Bean Validator를 인지하고 스프링에 통합한다. -> 스프링 부트는 LocalValidatorFactorBean을 글로벌 Validator(모든 컨트롤러에 적용되는 검증기)를 자동으로 등록한다. -> 검증이 필요..

Validation 6 에서는 Validator 인터페이스를 사용하여 컨트롤러에서 검증로직을 뺄 수 있었다.. 하지만, 그 한줄.. validator의 validate 메서드 호출하는 그 한줄.. 도 빼고 싶다.. WebDataBinder를 사용해보자. WebDataBinder 스프링의 파라미터 바인딩의 역할과 검증기능을 포함한다.. WebDataBinder에 구현한 Validator를 넣어주기만 스프링이 알아서 처리 해준다. init : 메서드 컨트롤러가 호출 될 때 마다.. 호출 되는 메서드이다. 요청이 올 때 마다 WebDataBinder가 생성되고 그 WebDataBinder에 주입받은 Validator가 추가된다. @InitBinder : 해당 클래스 컨트롤러에만 영향이 있다. 참고로 글로벌 설..

BindingResult 의 reject, rejectValue 메서드 사용에 의해 검증 로직이 한층 가벼워 졌다... 하지만, 컨트롤러의 입장에서 보면 아직도 코드가 길고 복잡하다... 위와 같이 하나의 메서드 컨트롤러에서 검증에서 성공했을때의 로직(컨트롤러에 진짜 들어가야할 로직) 보다.. 검증하는 로직이 대부분을 차지한다.. 이를 해결해보자.. Validator 스프링이 제공하는 검증을 위한 인터페이스이다. supports : 파라미터로 들어오는 clazz가 개발자가 의도한 검증할 클래스 타입인지 확인하는 메서드 validate : 개발자가 의도한 검증 로직이 들어간다. (참고로 validate의 파라미터 중, Errors는 BindingResult의 부모 클래스이다.) 인터페이스에 대해 알아보았으..

이전 포스팅에서 봤던 검증 로직에서.. BindingResult에 FieldError와 ObjectError를 생성해서 넣는 방식은 너무 파라미터도 많고 힘들다.. BindingResult가 파라미터로 있는 컨트롤러는 위 예시와 같이 검증 대상(Item) 바로 뒤에 위치하게 된다. 그렇다는 말은.. BindingResult는 이미 검증할 대상을 알고 있다는 말이다. (위 예시에서 bindingResult.getObjectName(), bindingResult.getTarget() 을 사용함에서 알 수 있다.) item item 객체 정보 출력 검증 대상을 이미 알고있기 때문에 좀 더 간단하게 검증 로직을 구현할 수 있다. rejectValue(), reject() 좀더 간단한 파라미터를 가지는 걸 볼 수..

오류 메세지도 일관성 있게 한군데에서 관리해보자 (메세지 국제화 처럼..) codes : 메세지 코드 arguments : 메세지에서 사용하는 인자 defaultMessage : 기본 오류 메세지 codes, arguments를 활용하면 메세지 국제화처럼 관리가 된다. (오류 발생시 오류 코드로 메세지를 찾기 위해 사용된다.) errors.properties 라는 별도의 파일을 만들어 관리 가능. application.properties 에 spring .messages.basename=messages, errors 라인 추가 (messages.properties 와 errors.properties 파일을 등록하겠다는 의미) controller> errors.properties>