과제 대다수 웹 애플리케이션에는 특별히 보안에 신경 써야 할 민감한 URL이 있다. 이런 URL에 미인가 외부 유저가 제약 없이 접근할 수 있도록 보안하라 해결책 스프링 시큐리티는 HTTP 요청에 서블릿 필터를 적용해 보안을 처리한다. AbstractSecurityWebApplicationInitializer라는 베이스 클래스를 상속하면 편리하게 필터들 등록하고 구성 내용이 자동 감지되게 할 수 있다. WebSecurityConfigurerAdapter라는 구성 어댑터에 준비된 다양한 configure() 메서드를 이용하면 웹 애플리케이션 보안을 쉽게 구성할 수 있다. 간단하고 일반적인 보안 요건은 구성 파일을 건드리지 않아도 아래 기본 보안 설정을 바로 적용할 수 있다. *폼 기반 로그인 서비스 : 유..

과제 서버/ 클라이언트가 웹에서 양방향 통신을 할 수 있게 하라 해결책 HTTP와 달리 전이중 통신이 가능한 웹소켓을 이용하면 서버/클라이언트가 서로 양방향 통신을 할 수 있다. 풀이 웹소켓 기술과 HTTP는 가까운 기술이다. 웹소켓에서 HTTP는 처음 한번 핸드셰이크를 할 때만 쓰이고 이후에는 접속 프로토콜이 일반 HTTP => TCP 소켓으로 업그레이드 된다. 웹소켓 지원 기능 설정 구성 클래스에 @EnableWebSocket만 붙이면 웹소켓 기능을 활용할 수 있다. @Configuration @EnableWebSocket public class WebSocketConfiguration { } 버퍼 크기, 타입아웃 등 웹소켓 엔진을 추가 설정할 경우 ServletServerContainerFactor..

과제 서블릿 API로 정의한 서블릿 필터는 서블릿 웹 요청을 처리하기 전후마다 원하는 선/후처리 로직을 수행할 수 있다. 스프링 웹 애플리케이션 컨텍스트의 필터 비슷한 뭔가를 구성해 컨테이너의 장점을 이용해보자 또한 스프링 MVC 핸들러가 담당하는 웹 요청을 선/후처리하는 과정에서 모델 속성을 뷰에 반환하기 전 조작해보자 해결책 스프링 MVC에서는 핸들러 인터셉터를 사용해 웹 요청을 가로채고 원하는 선/후처리를 할 수 있다. 핸들러 엔터셉터는 스프링 웹 애플리케이션 컨텍스트에 구성하기 때문에 컨테이너 기능을 얼마든지 꺼내쓸 수 있고 컨테이너에 선언된 빈은 전부 다 참조 가능하다. 핸들러 인터셉터는 특정 URL로 들어오는 요청만 적용되도록 설정할 수 있다. 스프링 HandlerInterceptor 인터페이..

과제 서비스에서 응답을 여러 청크로 나눠 전송하라 해결책 ResponseBodyEmitter(또는 SseEmitter)로 응답을 청크로 나눠 보낸다. 풀이 스프링에서는 HttpMessageConverter 인프라를 이용해서 어떤 객체를 평범한 일반 객체로 출력할 수 있다. 클라이언트는 청크된(또는 스트리밍된)리스트를 받게 된다. 결과를 객체 대신 이벤트 형태로 보내는 방법도 있다. 이를 서버 전송 이벤트라고 한다. 여러 결과를 하나의 응답에 실어 보내기 스프링 MVC의 ResponseBodyEmitter 클래스는 (뷰 이름 또는 ModelAndView 등) 하나의 결과 대신 여러 객체를 클라이언트에 반환할 때 유용하다. 반환할 객체는 HttpMessageConverter를 이용해 결과로 변환한 다음 전송..

INTRO 서블릿 API 초창기 시절엔 구현 컨테이너 대부분이 요청당 스레드 하나만 사용했다. 하지만 서블릿3 명세부터 HTTP 요청이 기하급수적으로 늘면서 HTTP 요청을 비동기로 처리할 수 있게 되었다. 서블릿3.1 호환 컨테이너에서 제대로 사용한다면 모든 작업을 넌블로킹 형태로 작동시킬 수 있다.(리소스 역시 넌블로킹 형태로 작동해야 한다.) 예전에는 웹 애플리케이션은 유저의 요청을 접수한 서버가 HTML을 렌더링하고 이를 다시 클라이언트에 돌려줬다. 지금은 HTML 렌더링 작업이 클라이언트로 넘어갔고 HTML을 직접 주는 방식이 아니라 JSON, XML등의 다른 표현형을 덜려주는 식으로 통신 방법이 바뀌었다. XMLHttpRequest, 서버 전송 이벤트, 웹소켓 등 흥미로운 기술들이 있다. 과제..

과제 : 컨트롤러 단위 테스트 스프링 MVC 프레임워크로 개발한 웹 애플리케이션의 컨트롤러 테스트하기 해결책 DispatcherServlet은 스프링 MVC 컨트롤러에 HTTP 요청/응답 객체를 전달하고 컨트롤러는 요청을 처리 후 뷰를 렌더랑하기 위해 다시 DispatcherServlet에 요청 객체를 반환한다. 스프링 MVC 컨트롤러를 단위 테스트할 때 신경써야 할 부분은 HTTP 요청/응답 객체를 모방하는 것이다. 스프링은 서블릿 API용 목 객체 세트를 제공하여 컨트롤러 단위 테스트를 지원한다. 스프링 MVC 컨트롤러를 테스트하려면 DispatcherServlet에 올바른 객체가 반환됐는지 확인해야 한다. 스프링에서 기본 제공되는 각종 assertion 유틸리티를 이용해 객체의 content를 확인..

과제 애플리케이션 모듈을 따로 분리해 테스트한 후 다시 조합해서 테스트하는 것이 가장 흔한 테스트 방식이다. 이 방식으로 애플리케이션을 테스트 해보자 해결책 단위 테스트의 쓰임새는 하나의 프로그램 단위를 테스트하는 것이다. 객체 지향 언어에서 단위란 보통 클래스나 메서드를 가리킨다. 단위 테스트의 범위는 하나의 단위 하나로 국한되지만 실제로 단위가 홀로 움직이는 일은 거의 없고 다른 단위와 함께 작동되는 경우가 대부분이다. 다른 단위와 의존 관계를 지닌 단위를 테스트할 때에는 보통 스텁이나 목 객체로 단위 간 의존 관계를 모방해서 테스트의 복잡도를 낮춘다. 스텁은 테스트에 필요한 최소한의 메서드만으로 의존 객체를 시뮬레이션한 객체로, 보통 메서드는 사전에 정해진 로직으로 하드 코딩한 데이터를 이용해 구현..

과제 애플리케이션 모듈을 따로 분리해 테스트한 후 다시 조합해서 테스트하는 것이 가장 흔한 테스트 방식이다. 이 방식으로 애플리케이션을 테스트 해보자 해결책 단위 테스트의 쓰임새는 하나의 프로그램 단위를 테스트하는 것이다. 객체 지향 언어에서 단위란 보통 클래스나 메서드를 가리킨다. 단위 테스트의 범위는 하나의 단위 하나로 국한되지만 실제로 단위가 홀로 움직이는 일은 거의 없고 다른 단위와 함께 작동되는 경우가 대부분이다. 다른 단위와 의존 관계를 지닌 단위를 테스트할 때에는 보통 스텁이나 목 객체로 단위 간 의존 관계를 모방해서 테스트의 복잡도를 낮춘다. 스텁은 테스트에 필요한 최소한의 메서드만으로 의존 객체를 시뮬레이션한 객체로, 보통 메서드는 사전에 정해진 로직으로 하드 코딩한 데이터를 이용해 구현..

스프링 테스트 컨텍스트 프레임워크에 구현된 스프링 테스트 지원 기능은 하부 테스트 프레임워크를 다음과 같은 개념으로 추상화한다. - 테스트 컨텍스트 => 애플리케이션 컨텍스트, 테스트 클래스를 비롯해 현재 테스트의 인스턴스, 메서드, 실행 등 테스트의 실행 컨텍스트를 캡슐화한다. - 테스트 컨텍스트 관리자 => 테스트 컨텍스트를 관리하는 주체다. 테스트 인스턴스를 준비하는 시점, 테스트 메서드 실행 이전, 테스트 메서드 실행 이후 등의 테스트 실행 시점에 미리 테스트 실행 리스너를 트리거한다. - 테스트 실행 리스너 => 리스너 인터페이스를 정의한다. 이 인터페이스를 구현하면 테스트 실행 이벤트를 리스닝할 수 있다. 테스트 컨텍스트 프레임워크는 자주 쓰는 테스트 기능에 맞춰 테스트 실행 리스너를 제공하지..