서블릿은 세션 기능을 개발자를 위하여 이미 제공하고 있다. HttpSession 직전 포스팅의 SessionManager와 비슷한 기능을 담당하지만.. 실제 설계 내용은 많이 다른것 같다. HttpSession이 생성되면, 클라이언트와 서버간의 Cookie가 생성되고 key는 JSESSIONID value는 추정불가능한 임의의 값이다. SessionManager 1개 WAS에 1개 세션(세션 저장소, SessionManager) 여러 클라이언트가 동일한 세션을 바라본다. -> 쿠키에는 mySessionId:임의의 값으로 들어간다. -> SessionManager에는 임의의 값이랑 loginMember(member 객체) 가 매핑될 수 있는 메모리 테이블이 존재한다. -> HttpSession과 구조가 달..

쿠키, 세션 1 포스팅에서 로직은 문제가 있다. 클라이언트와 서버간 전송되는 쿠키에는 memberId가 포함되어 전송된다. 해당 쿠키는 중요한 정보이므로 .. 해당 정보를 전송하는 일은 없어야 하며, 쿠키에 시간제한을 두어 일정 시간이 지나면 다시 재사용 불가능하도록 만들어야 한다. 중요한 정보를 전송하지 않고 쿠키를 이용하여야 한다. -> 추정이 불가능한 임의의 값으로 연결 해야 한다는 말이다. -> 서버에 중요한 정보를 놔두고 임의의 값으로 매핑시켜 연결을 유지 -> 이러한 방법을 세션이라 부른다. 그림으로 알아보자.. 위와 같이 세션 저장소를 서버에 놔둔다. -> 쿠키로 사용할 임의의 값과 중요한 정보를 매칭 시킬 수 있는 테이블 (메모리 영역) 클라이언트가 쿠키를 보내면 서버는 해당 쿠키(임의의 ..

쿠키 서버에서 로그인에 성공하면 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의 부모 클래스이다.) 인터페이스에 대해 알아보았으..