Spring Boot를 Initializer를 통해 설정할 때, 아직 url이 존재하지 않아서 애플리케이션을 실행하면 오류가 생기는 경우가 있다.

이럴 경우에 물론 데이터베이스 url을 설정하면 바로 해결할 수 있지만 그렇게 하지 않고 실행이 되도록 할 수 있는 방법이 있다.

자동으로 데이터베이스 Configuration Auto로 설정된 것을 exclude하게 되면 데이터베이스를 설정하고자 하는 트라이를 하지 않게 된다.

HTTP 메시지 컨버터는 언제 사용되는 것인가

클라이언트에서 서버로 요청 데이터를 전달할 때는 3가지 방법이 있다.

첫번째는 GET 메소드를 통한 쿼리 파라미터로 전달하는 방법이다.
이 때 url은 보통 /board?page=1&year=2024 이런식으로 메시지 바디 없이, URL의 쿼리 파라미터에 데이터를 포함해서 전달한다.

두번째는 POST 메서드를 통해 HTML form 데이터를 보낼 수 있다. 메시지 바디에 쿼리 파라미터 형식으로 page=1&year=2024 형식으로 전달한다.

첫번째와 두번째 방법의 공통점은 둘 다 요청 데이터를 request.getParameter()로 데이터를 읽어서 처리할 수 있다는 것이다.

세번째 방법은 HTTP message body에 데이터를 직접 담아서 요청하는 방법이다.

이 방법을 사용하게 될 때 HTTP 메시지 컨버터가 사용되게 된다.

HTTP message body를 통해 데이터가 직접 넘어오는 경우에는 @RequestParam 이나 @ModelAttribute와는 상관이 없다.
이 2가지 어노테이션은 요청 파라미터를 처리하는 것이고, 세번째 방법과 관련된 어노테이션은 @RequestBody와 @ResponseBody이다.

서버에서 클라이언트로 응답 데이터를 만드는 방법도 3가지이다.

첫번째는 정적 리소스 자체를 제공해주는 것, 두번째는 뷰 리졸버를 사용하는 뷰 템플릿을 사용하는 방법이다.

세번째는 HTML을 제공하는 것이 아니라 JSON 형태의 데이터를 전달하는 HTTP 메시지를 사용하는 방법이 있다.

이 세번째 방법에 HTTP 메시지 컨버터가 사용되게 된다.

언제 사용되게 되는지 보았을때 '데이터'를 사용할 때 HTTP 메시지 컨버터가 사용되는 것으로 보인다.
즉, HTTP 메시지 컨버터는 메시지 바디의 내용을 우리가 원하는 문자(String)이나 객체 등으로 변환해준다.

HTTP 메시지 컨버터는 왜 사용하는 것인가

만약에 JSON 데이터를 메시지 바디에 넣어서 요청을 하거나 응답을 할 때 사용한다고 생각해보자.

먼저 요청의 경우, 클라이언트가 보낸 JSON 데이터를 읽어서 서버가 처리를 하려면 스트림 처리를 해야된다.
즉, requestStream을 읽어서 직접 JSON으로 변환을 했어야 한다.

또한 응답의 경우도 JSON 데이터를 HTTP 메시지 바디에 넣어서 반환을 하려면 response.getWriter()로 직접 넣는 작업이 필요하다.

이런 부분이 불편하기 때문에 스프링은 HTTP 메시지 컨버터라는 것을 제공해준다.

HTTP 메시지 컨버터는 알아서 변환하여 HTTP 메시지 바디를 읽거나 쓰는 것을 도와준다.

HTTP 메시지 컨버터 사용

스프링은 다음 어노테이션의 경우 HTTP 메시지 컨버터를 적용한다.

1. @RequestBody, HttpEntity(RequestEntity)
2. @ResponseBody, HttpEntity(ResponseEntity)

HTTP 메시지 컨버터는 요청과 응답 둘 다 사용된다. 컨버터는 양방향이다.

• canRead() , canWrite() : 메시지 컨버터가 해당 클래스, 미디어 타입을 지원하는지 체크.
• read() , write() 메시지 컨버터를 통해서 메시지를 읽고 쓰는 기능

@ResponseBody의 사용 원리

만약 @ResponseBody 를 사용한다면

• HTTP의 body에 문자 내용을 직접 반환한다.
• viewResolver 대신에 HttpMessageConverter 가 동작하게 된다.
• 기본 문자처리는 StringHttpMessageConverter 가 처리한다.
• 기본 객체처리는 MappingJackson2HttpMessageConverter 가 처리한다.
  • 이건 Json으로 바꿔주는 ObjectMapper를 통해서 객체가 json으로 바뀌어서 응답 메시지에 넣어져서 나간다.
• 이외에 byte 처리 등등 기타 여러 HttpMessageConverter가 기본으로 등록되어 있다.

클라이언트의 HTTP Accept 헤더와 서버의 컨트롤러 반환 타입 정보 둘을 조합해서 HttpMessageConverter 가 선택된다.

HTTP 메시지 컨버터의 구성

HTTP 메시지 컨버터는 인터페이스로 되어있다.

이유는 Json으로 처리해주는 컨버터, String으로 처리해주는 컨버터 등등 여러가지가 있기 때문이다.

그래서 위에서 말한대로 응답의 경우 HTTP Accept 헤더와 서버의 컨트롤러 반환 타입 정보를 확인해서 선택하게 된다.

String은 StringHttpMessageConverter, Json은 MappingJackson2HttpMessageConverter가 각각 처리해준다.

스프링 부트는 다양한 메시지 컨버터를 제공하는데, 대상 클래스 타입과 미디어 타입 둘을 체크해서 HTTP 메시지 컨버터의 사용여부를 결정한다.

→ 여기서 미디어 타입이라는 것은 Http 요청 메시지에서 메시지 바디에 있는 content-type이 무슨 타입이라고 알려주는 것이다.

예를 들어서 content type이 application/json이다. 그러면 '메시지 바디에 있는게 json 이구나!' 하면서 해당 메시지 컨버터가 선택이 되는 것이다. 그것만 따지는 것이 아니고 대상 클래스의 type 그리고 media-type 둘 다 체크해서 사용 여부를 결정한다.

만약 여기서 만족하지 않으면 canRead, canWrite 를 실행해서 다음 컨버터로 넘어가게 되는 것이다.

(우선순위는 높은 순서대로 0은 Byte, 1은 String, 2는 Json, ..)

그래서 항상 HTTP 메시지에 body 데이터가 있다면 그 컨텐츠 타입을 지정해줘야 한다

HTTP 메시지 컨버터가 데이터를 처리하는 과정

HTTP 요청이 오면 컨트롤러에서 @RequestBody나 HttpEntity 파라미터를 사용한다면 메시지 컨버터가 메시지를 읽을 수 있는지 확인하기 위해서 canRead() 를 호출한다.

그럼 먼저 대상 클래스 타입을 지원하는가를 확인하고, HTTP 요청의 Content-Type 미디어 타입을 지원하는가를 확인한다.

조건을 만족하면 Read를 호출해서 객체를 생성하고 그 컨트롤러의 파라미터로 넘겨준다.

응답 데이터 같은 경우에는 컨트롤러에서 @ResponseBody 이거나 HttpEntity 로 반환이 되면 메시지 컨버터가 메시지를 쓸 수 있는지 확인하기 위해서 canWrite() 를 호출한다.

호출해서 대상 클래스 타입을 지원하는가를 확인하고, HTTP 요청의 Accept 미디어 타입을 지원하는가를 같이 보게 된다.

즉, 요청의 경우에는 Content-Type에 Media-Type을 확인하고 응답이 나갈때는 HTTP 요청 메시지에 있는 Accept 미디어 타입을 지원하는지.

(클라이언트가 읽을 수 있는 메시지를 서버가 줘야하기 때문에 HTTP 요청에 Accept Media Type을 지원하는가도 추가적으로 체크를 하는 것이다. )

그럼 HTTP 메시지 컨버터는 스프링 MVC에서 어디쯤에서 사용되는 것일까?

이것은 @RequestMapping 을 처리하는 핸들러 어뎁터인 @RequestMappingHandlerAdapter와 관련이 있다.

HTTP 요청을 Spring이 처리하는 과정을 생각해보면,

먼저 실제로 HTTP 요청이 오게 되면 DispatcherServlet은 핸들러 매핑에게 해당 요청을 처리할 수 있는 핸들러를 조회하도록 위임한다.

그럼 등록되어 있는 핸들러 어댑터 중에 해당 핸들러를 처리할 수 있는 핸들러 어댑터를 조회한다.

다음 이 핸들러 어댑터를 통해서 실제 컨트롤러가 호출이 된다. (핸들러를 @Controller에 정의한 요청을 처리하는 처리기라고 생각하면 된다)

여기서 나누어 지게 되는데, 핸들러(컨트롤러)의 리턴값을 보고 어떻게 처리할지 판단한다.

만약에 View의 경우 뷰 이름에 해당하는 뷰를 찾아서 모델 데이터를 렌더링하는 것이고, @ResponseBody가 있다면 Converter를 사용해서 응답을 처리하게 되는 것이다.

어노테이션 기반의 컨트롤러의 여러 파라미터를 만들어서 호출할 수 있는 것이 바로 이 핸들러 어댑터에서 HTTP 메시지 컨버터와 관련이 있는 것이다.

그럼 요청 매핑 핸들러 어댑터(@RequestMappingHandlerAdapter)가 어떤 식으로 동작할까?

우리가 Spring을 통해서 Controller를 구성할 때, @ModelAttribute 이든, InputStream 이든 HttpEntity 같은 것들을 함수의 파라미터로 사용한다. 그러면 이걸 누군가 이런 함수의 파라미터들을 데이터로 전달해주어야 한다.

여기서 ArgumentResolver라는 개념이 나오게 된다.

ArgumentResolver와 HTTP 메시지 컨버터

RequestMappingHandlerAdapter는 ArgumentResolver라는 매개변수를 처리해주는 것이 있다.
(argument가 파라미터, 매개변수를 의미하고 스프링에서 Resolver라는 것이 나오면 뭔가를 처리해주는 것을 의미한다.)

생각해보면 어노테이션 기반의 컨트롤러는 매우 다양한 파라미터를 사용할 수 있다. 이렇게 파라미터를 유연하게 처리할 수 있는 이유가 바로 ArgumentResolver 덕분이다.

핸들러 어댑터 혼자 처리하기 어려워서 ArgumentResolver를 사용해서 필요한 객체들을 생성하게 된다. 그리고 ArgumentResolver가 MessageConverter를 사용하게 되는 것이다.

어노테이션 기반 컨트롤러를 처리하는 RequestMappingHandlerAdaptor 는 바로 이 ArgumentResolver 를 호출해서 컨트롤러(핸들러)가 필요로 하는 다양한 파라미터의 값(객체)를 생성한다. 그리고 이렇게 파라미터의 값이 모두 준비되면 컨트롤러를 호출하면서 값을 넘겨준다. 스프링은 30개가 넘는 ArgumentResolver를 기본으로 제공한다.

여기서 supportsParameter가 해당 파라미터를 지원하는지 확인한다. 반환타입이 Object이다.

즉, ArgumentResolver의 supportsParameter() 를 호출해서 해당 파라미터를 지원하는지 체크하고, 지원하면 resolveArgument()를 호출해서 실제 객체를 생성한다. 그리고 이렇게 생성된 객체가 컨트롤러 호출 시 넘어가게 되는 것이다.

반환할 때도 언제는 View, 언제는 ModelAndView 이런식으로 되게 많은데 이걸 처리해주는 것도 인터페이스가 되어있다. ReturnValueHandler 이다.

ReturnValueHandler도 응답 값을 반환하고 처리한다. 그래서 컨트롤러에서 String으로 뷰 이름만 반환해도 동작하는 이유가 바로 ReturnValueHandler 덕분이다.

여기까지 알고 이제 HTTP 메시지 컨버터는 어디서 동작할까? 이건 ArgumentResolver랑 ReturnValueHandler가 사용하는 것이다.

ArgumentResolver는 Argument를 찾는 거고 그 ArgumentResolver들 중에서 HTTP 메시지 바디에 있는 걸 바로 뭔가 처리해야 된다고 하면 메시지 컨버터를 호출한다.

스프링은 ArgumentResolver, ReturnValueResolver, MessageConverter 세가지를 모두 인터페이스로 제공한다. OCP 원칙을 지키면서 확장할 수 있다.

즉, ArgumentResolver는 Controller에 선언된 Parameter를 생성하는 역할, ArgumentResolver가 MsgConverter를 사용하는 것이다.

웹 브라우저가 HTTP 요청을 하게 되면 HTTP Header, Body 등 웹 브라우저에서 보낸 다양한 정보가 서버로 넘어가게 된다.

웹 브라우저가 HTTP 요청을 하면 해당 메시지를 서버가 받아서 메시지를 파싱도 하고, URL이 뭔지 판단도 하고, content-type도 넘어오니까, 원하는 정보를 몇 글자인지 보고 파싱해서 사실하면 로직을 처리할 수 있다. 거기에 response를 client에게 전달해 주면 된다. 그러나, 이런 작업은 반복적인 작업도 많고, 단순한 비즈니스 로직 하나를 처리하기 위해서도 귀찮은 일이 생긴다. 이걸 더 편리하게 해 주기 위해서 나온 게 서블릿이다.

서블릿은 이런 HTTP 작업을 단순화해 준다. HTTP 요청 정보를 편리하게 사용할 수 있는 HttpServletRequest 객체와 HTTP 응답 정보를 편리하게 사용할 수 있는 HttpServletresponse 객체를 제공해 줘서, 개발자는 HTTP 스펙을 쉽게 사용할 수 있게 되는 것이다.

서블릿(Servlet)

• 자바 웹 애플리케이션 개발을 위한 기술로, 동적인 웹 콘텐츠를 생성하는 데 사용
• HTTP 요청과 응답을 처리하기 위한 자바 클래스
• 서블릿 컨테이너(예: Apache Tomcat)에서 실행되며, 요청에 대한 처리와 스레드 관리를 담당

HTTP 요청과 응답을 서블릿이 어떻게 처리해주는지 알아보자.

1. HTTP 요청이 들어오면 WAS는 Request 객체랑 Response 객체를 새로 만들어서 서블릿 객체를 호출한다.
2. 그럼 Request 객체에서 HTTP로 어떤 요청이 들어왔는지 확인하고
3. 해당 로직을 처리한 다음(해당 로직을 처리 주는 것이 바로 서블릿 객체이다)
4. Response 객체에 Client에게 전달해야 할 응답 정보를 담아서 전달해 준다. 이때 WAS가 HTTP 응답 정보를 생성해 준다.
5. Client가 해당 정보로 렌더링 해서 이제 보여준다.

서블릿 컨테이너

WAS 안에는 서블릿 컨테이너라는 게 있는데 서블릿 컨테이너가 서블릿 객체를 자동으로 생성해 준다. 호출도 해주고, 관리까지(예를 들면 WAS 종료될 때 서블릿도 같이 종료시키는) 해준다. 톰캣은 서블릿 컨테이너의 종류 중 하나이다.

즉, WAS는 웹 서버와 서블릿 컨테이너로 구성된다고 생각하면 된다. 사실 경계가 모호하기 때문에 종류로 생각하는 게 편하다. 

웹 서버는 nginx와 apache가 해당하는 것이고, 서블릿 컨테이너는 apache tomcat(아파치 톰캣)이 해당한다.

서블릿 컨테이너의 장점 중 하나는 싱글톤으로 관리된다라는 사실이다. 싱글톤은 객체를 하나만 생성해놓고 서로 공유해서 사용하는 디자인 패턴을 의미한다. 만약 사용자가 10000명 이상으로 온다면 비즈니스 로직으로 개게를 엄청나게 만들어야 되는데, 싱글톤을 사용하면 하나를 공유해서 사용하면 되므로 딱 봐도 이점이 느껴진다.

그렇다고, request랑 response를 다 공유하는 건 아니다. 웹 브라우저에서 사용자마다 전달해오는 데이터는 당연히 다를 것이다.

(내 아이디 비번과 다른 사람의 아이디 비번이 다른 것과 마찬가지이다)

request, response 객체는 따로 생성하지만 비즈니스 로직인 서블릿은 공유해서 사용하는 것이다. 항상 재사용한다. 그래서 모든 고객 요청은 동일한 서블릿 객체 인스턴스에 접근하게 된다. (그래서 공유 변수 사용에 주의해야 한다)

또 다른 중요한 장점은 서블릿 컨테이너는 멀티 스레드 처리도 지원을 한다는 사실이다. 

위에 그림처럼 request가 생기면 서블릿을 호출하게 되는데, 그럼 서블릿은 누가 호출하는 건가??

쓰레드가 호출하게 된다. 스레드는 애플리케이션의 흐름이라고 알고 있는데, 말 그대로이다. 스레드가 아무 작업을 안 하고 쉬고 있다가, 만약에 요청이 들어오면 스레드를 할당해 줘서 서블릿을 호출해 주는 시스템인 것이다. 요청하고 응답까지 다 하면, 스레드는 다시 휴식하게 되는 것이다. 

다중 요청이 들어올 때도, 쓰레드가 여러 개면 해결이 될 것 같다. 요청마다 스레드를 생성해 주면 되는 것이다. 이렇게 생각했는데 이 방법은 당연히 단점이 있다. 

장점으로는 동시 요청을 처리하면서, 하나의 쓰레드가 지연되어도, 나머지 스레드는 정상 동작하기 때문에 상관이 없다.

그렇지만 쓰레드는 생성 비용이 매우 비싸고, 고객의 요청이 올 때마다 새로운 스레드를 생성하면 응답 속도가 늦어지고, 고객 요청이 너무 많이 오면 결국 임계점을 넘기면 서버가 죽을 수도 있는 것이다. 

근데 WAS는 멀티 스레드를 다 처리해주기 때문에 멀티 스레드 관련 코드를 신경 안 써도 된다.

웹 서블릿의 동작 원리

@WebServlet(name = "helloServlet", urlPatterns = "/hello")
public class HelloServlet extends HttpServlet {

    @Override
    protected void service(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {

        System.out.println("HelloServlet.service");
        System.out.println("request = " + request);
        System.out.println("response = " + response);

        String username = request.getParameter("username");
        System.out.println("username = " + username);

        response.setContentType("text/plain");
        response.setCharacterEncoding("utf-8");
        response.getWriter().write("hello " + username);


    }
}

위의 코드를 한번 살펴보자. @WebServlet 어노테이션을 선언해주면 이제 서블릿 컨테이너가 관리를 해주게 되는 것이다. 

서블릿은 클라이언트의 요청을 HTTP 형태로 받는다. @WebServlet 어노테이션의 Parameter로는 name과 urlPatterns를 받는다.

단어 그대로, name은 서블릿의 이름이고, urlPattern은 클라이언트에서 요청하는 URL이다. 이 둘을 매핑해 주는 것이다.

만약 HTTP를 통해 매핑된 URL이 호출되면 서블릿 컨테이너는 다음 메서드를 실행한다.

protected void service(HttpServletRequest request, HttpServletResponse response);

위의 함수 파라미터 그대로 해석하면 request에는 클라이언트 요청, response는 서블릿이 이제 대답을 준다. 해당 함수를 어떻게 커스터마이징하고 조작하는 역할을 이제 서블릿 컨테이너 안의 서블릿이 해주는 것이다. 그 조작을 service함수 내에서 하면 되는 것이다.

그래서 서블릿의 이름과 urlPattern은 중복되게 하면 안된다. 

그럼 위의 코드에서 request 객체와 response 객체에는 어떤 것들이 오는지 로그를 찍어보자.

apache.catalina는 tomcat쪽 라이브러리이다.(서블릿 컨테이너 쪽 라이브러리)

HttpServletRequest나 HttpServletResponse는 interface이다.

이제 Tomcat이나 Jetty 등등 이런 WAS 서버들이 서블릿 표준 스펙을 구현하는 것이다. 여기 찍히는 것은 Tomcat의 구현체라고 볼 수 있다.

쿼리 파라미터

서블릿의 장점 중 하나는 쿼리 파라미터를 아주 쉽게 읽을 수 있게 해 준다는 사실이다.

request로 query parameter를 전송하면 request 객체에서 getParameter를 사용하면 해당 query 파라미터를 읽어낼 수 있다.

응답 메시지를 보여줄려면 response에 넣어줘야 한다.

setContentType를 text/plain으로 준다면 단순 문자열을 전송해 주는 것이다.

setCharacterEncoding은 utf-8로 둔다.

그럼 여기까지 정보는 Header에 들어가게 된다.

나머지는 response.getWriter().write() 를 통해서 보내준다.

모든 HTTP 요청 응답 정보들을 보고 싶으면 아래와 같이 설정하면 된다. (application.properties)

logging.level.org.apache.coyote.http11=debug

지금까지의 동작 과정

1. 스프링부트로 프로젝트를 생성 후 실행 → 스프링부트 안에 있는 내장 톰캣 서버를 띄워준다.
2. 톰캣 서버는 내부에 서블릿 컨테이너를 가지고 있다.
3. 서블릿 컨테이너를 통해서 내부에 서블릿을 다 생성해준다. → HelloServlet 생성
4. GET /hello?username=kim HTTP/1.1 Host: localhost:8080 웹브라우저가 이런 형식으로 HTTP 메시지를 만들어서 서버에 요청을 한다.
5. 서버는 Request, Response 객체를 만들어서 HelloServlet의 Service 메서드를 호출하면서 response 객체를 만들어서 웹 브라우저에게 전달해 준다.
6. HTTP 응답에서 Content-Length는 웹 애플리케이션 서버가 자동으로 생성해 준다. (WAS가 해줌)

HttpServletRequest의 역할

위에서 말했듯이 HTTP 요청 메시지를 개발자가 직접 파싱 하기 어려우니까, 서블릿은 개발자가 HTTP 요청 메시지를 편리하게 사용할 수 있도록 개발자 대신에 HTTP 요청 메시지를 파싱 한다. 그리고 그 결과를 HttpServletRequest 객체에 담아서 제공한다.

추가적인 역할

1. 임시 저장소 기능 : HTTP 요청이 시작부터 끝날 때까지 유지되는 임시 저장소 기능
   1. 저장 : request.setAttribute(name, value)
   2. 조회 : request.getAttribute(name)
2. 세션 관리 기능 : request.getSession(create: true)

클라이언트에서 HTTP를 통해 서버로 전달하는 방법

1. GET - 쿼리 파라미터
   1. 검색, 필터, 페이징 등에서 많이 사용하는 방식
   2. 서버는 HttpServletRequest를 가지고 정보를 쉽게 가져올 수 있다
2. POST - HTML Form
   1. content-type: application/x-www-form-urlencoded
   2. 메시지 바디에 쿼리 파라미터 형식으로 전달 → 똑같이 request.getParameter로 꺼낼 수 있다!
   3. 클라이언트 입장에서는 차이가 있는데, 서버 입장에서는 둘의 형식이 동일한 것이다
   4. 회원가입, 상품 주문에 사용
3. HTTP message body에 데이터를 직접 담아서 요청
   1. HTTP API에서 주로 사용, JSON형식으로 사용
   2. POST, PUT, PATCH
   3. String으로 주고 받는 방식(잘 쓰이지 않음)

@WebServlet(name = "requestBodyStringServlet",urlPatterns = "/request-body-string")
public class RequestBodyStringServlet extends HttpServlet {
    @Override
    protected void service(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
        ServletInputStream inputStream = request.getInputStream();
        String messageBody = StreamUtils.copyToString(inputStream, StandardCharsets.UTF_8);
        System.out.println("messageBody = " + messageBody);
        response.getWriter().write("OK");

    }
}

• getInputStream을 하면 메시지 body의 내용을 byte코드로 바로 얻을 수 있다
• byte 코드를 String으로 바꿔야 하는데 Spring에 StreamUtils라는 유틸리티 클래스를 사용하면 된다.
  • 인코딩 정보를 알려줘야 한다
• 지금 이건 String 형식으로 주고 받는 것이다.
• JSON으로 주고 받는 방식이 보통 사용되는데 코드는 아래와 같다.

@WebServlet(name = "requestBodyJsonServlet", urlPatterns = "/request-body-json")
public class RequestBodyJsonServlet extends HttpServlet {

    private ObjectMapper objectMapper = new ObjectMapper();

    @Override
    protected void service(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
        // request
        ServletInputStream inputStream = request.getInputStream();
        String messageBody = StreamUtils.copyToString(inputStream, StandardCharsets.UTF_8);

        System.out.println("messageBody = " + messageBody);
        HelloData helloData = objectMapper.readValue(messageBody, HelloData.class);
        System.out.println("helloData.username = " + helloData.getUsername());
        System.out.println("helloData.age = " + helloData.getAge());

    }
}

// HelloData
@Getter @Setter
public class HelloData {

    private String username;
    private int age;

}

• 스프링은 JSON 라이브러리를 기본적으로 jackson이라는 것을 사용한다.
• ObjectMapper를 선언하고 readValue를 통해서 class타입으로 변환할 수 있다. 여기서는 HelloData로 변환을 하였다.
• 나중에는 MVC가 제공하는 기능을 통해서 더 쉽게 JSON을 파싱할 수 있다

서블릿과 자바로 동적으로 변경해야 하는 부분을 보여주고 싶을 때 템플릿 엔진을 사용할 수 있다. 템플릿 엔진을 사용하면 HTML 문서에서 필요한 곳만 코드를 적용해서 동적으로 변경할 수 있다.

템플릿 엔진에는 JSP, Thymleaf, Freemarker, Velocity 등이 있다. 이전에는 JSP가 많이 사용되었었지만, 스프링은 현재 Thymeleaf를 사용하는 걸 추천한다.

단순히 서블릿만을 사용하기에는 HTML을 다루기가 너무 힘들기 때문에 JSP나 타임리프 같은 것들을 사용하게 된다.

JSP(JavaServer Pages)

• 서블릿을 기반으로 하는 웹 페이지 개발을 위한 기술
• HTML 코드 내에 자바 코드를 삽입하여 동적인 웹 콘텐츠를 생성할 수 있다
• JSP 파일은 서블릿으로 변환되어 서블릿 컨테이너에서 실행

서블릿과 JSP의 한계

분리되어 있지 않다. 이게 제일 핵심 단점이다. 서블릿과 JSP를 사용하다 보면 비즈니스 로직이랑 화면(View)랑 분리되지 않아서 지저분하고 나중에 코드를 볼 때도 복잡하여 유지보수가 어렵다. 

그래서 등장하게 된 것이 MVC 패턴이다.

MVC 패턴

MVC 패턴은 컨트롤러와 뷰라는 영역으로 서로 역할을 나눈다. MVC 용어에서 알 수 있듯이 여기서 V는 view이고, C는 Controller이다.
M은 모델인데, 모델은 뷰에 출력할 데이터를 담아두고 뷰가 필요한 데이터를 모두 모델에 담아서 전달한다. 덕분에 뷰는 비즈니스 로직이나 데이터 접근 같은 걸 몰라도 되고, 화면만 렌더링 하면 되는 것이다.

그리고, Service로도 이후에 나눈다. Controller에 비즈니스 로직을 둘 수도 있지만 이렇게 되면 또 컨트롤러가 부담을 많이 지는 문제가 발생하기 때문에 Service 계층을 따로 나누어서 처리한다. Controller는 서비스 계층을 호출하는 역할만 하면 된다.

MVC 패턴과 관련된 프레임워크도 많았었는데, 어노테이션 기반의 스프링 MVC가 나오면서 거의 정리되었다. 

MVC 패턴의 한계

MVC 패턴의 한계라기보다는 MVC 패턴을 개선하는 방안이다. MVC 패턴은 요청하는 부분과 응답하는 부분, 즉 request response 코드가 controller마다 따로 구성되어 있다. 중복된 코드는 항상 개선점에 해당한다. 그래서 FrontController라는 것이 고안되었다.

FrontController 패턴

• Front Controller 패턴은 소프트웨어 디자인 패턴 중 하나로, 웹 애플리케이션에서 중앙 집중화된 컨트롤러 역할을 수행하는 컴포넌트
• 이 패턴은 클라이언트의 모든 요청을 하나의 진입점으로 보내고, 해당 요청을 처리하기 위해 적절한 핸들러(컨트롤러)로 라우팅 하는 구조를 가지고 있다
• Front Controller를 제외한 나머지 Controller는 서블릿을 사용하지 않아도 된다.

스프링 웹 MVC에서 보면 FrontController를 사용한다. 우리가 DispatcherServlet으로 알고 있는 것이 FrontController 패턴으로 구현되어 있다. 프런트 컨트롤러 서블릿이 클라이언트 요청을 다 받고 프런트 컨트롤러가 요청에 맞는 컨트롤러를 찾아서 호출하는 즉, 입구를 하나로 만드는 전략이다.

개선점

위의 서블릿 코드에서 override 된 service코드를 보면 HttpServletRequest랑 HttpServletResponse를 계속하여 쓰게 되는데, 해당 코드가 컨트롤러 입장에서는 필요 없다. Controller는 View로 객체를 전달하기만 하면 되는데, 해당 객체를 Model 객체라고 한다. 그럼 이제 우리가 아는 구조가 나오게 된다.

전형적인 Front Controller 패턴의 구조는 다음과 같다:

1. 클라이언트는 요청을 Front Controller에게 전송
2. Front Controller는 요청을 받아 해당 요청을 처리할 적절한 핸들러(컨트롤러)로 라우팅
3. 핸들러는 요청을 처리하고 필요한 작업을 수행한 후 응답을 생성
4. Front Controller는 핸들러로부터 받은 응답을 클라이언트에게 전송

뷰 리졸버 (View Resolver)

뷰 리졸버(View Resolver)는 컨트롤러가 처리한 결과를 어떤 뷰로 보여줄지를 결정하는 역할을 한다.
뷰 리졸버는 뷰의 논리적인 이름을 실제 뷰 객체로 변환하여 반환하는 기능을 담당한다.

웹 애플리케이션은 MVC (Model-View-Controller) 아키텍처를 따르는데, 이 구조에서 컨트롤러는 요청을 처리하고 필요한 작업을 수행한 후 결과를 뷰에 전달한다. 뷰 리졸버는 컨트롤러가 반환한 뷰의 논리적인 이름을 실제 뷰 객체로 매핑하여 클라이언트에게 보여줄 뷰를 결정하게 되는 것이다.

Spring MVC

• Spring Framework에서 제공하는 웹 애플리케이션 개발을 위한 모듈
• Model-View-Controller(MVC) 아키텍처 패턴을 기반으로 한다
• 요청을 처리하는 컨트롤러(Controller), 데이터를 처리하는 모델(Model), 화면을 표현하는 뷰(View)로 구성
• 애노테이션 기반의 설정과 느슨한 결합을 통해 유연하고 효율적인 웹 애플리케이션 개발을 지원
• 요약하면, 서블릿은 자바 기반의 웹 애플리케이션 개발을 위한 기술이고, JSP는 서블릿을 기반으로 동적인 웹 페이지를 개발하기 위한 기술
• Spring MVC는 Spring Framework에서 제공하는 모듈로, 웹 애플리케이션 개발을 위한 MVC 패턴을 구현하는 방식
• Spring MVC는 서블릿과 JSP를 기반으로 하며, 개발자에게 편의성과 유연성을 제공하여 웹 애플리케이션 개발을 보다 쉽게 할 수 있도록 도와준다

참고 : 인프런 김영한 님 스프링 MVC 편

이전에 웹 브라우저의 세션을 이용해서 로그인과 회원가입을 구현하고 쿠키에 저장하는 방법을 통하여 로그인 회원가입을 처리해본 경험이 있다.
하지만 세션과 쿠키를 사용하는 것에는 단점들이 있다. 먼저 jwt는 STATELESS하므로 상태를 저장하지 않는 RESTful API에 적합하였고, 모바일 환경에서도 쉽게 사용할 수 있다는 장점이 있었다.

해당 내용을 바탕으로 JWT와 스프링 시큐리티를 사용하여 로그인, 회원가입, JWT 토큰을 이용한 나의 정보 확인 이렇게 3가지 기능을 동작하도록 만들었다.

먼저 3가지 기능에 해당하는 내가 만든 API endpoint는 다음과 같다.

1. /members/login
2. /members/signup
3. /members/check

이제 스프링 시큐리티와 JWT를 알아보면서 해당 기능들을 구현해보겠다.

스프링 시큐리티, 사용이유

원리 : 서블릿 필터를 이용한다.

Spring의 내부 원리는 사용자(client)가 api를 호출하면 servlet container(tomcat)가 받고, request 받은 것을 spring의 dispatcherservlet에게 요청하게 된다. 요청에 따라서 controller에게 전달하고 서블릿 컨테이너가 응답을 받아서 사용자에게 전달한다.

servlet container에서 spring dispatcher servlet까지 전달될때까지 개입을 할 수 있는데, 개입을 필터를 적용해서 할 수 있다. 즉, servlet 객체들이 dispatcher servlet에 도착하기 전에 필터체인을 통과한 뒤에 dispatcherservlet에 도착하게 되는 것이다.

따라서 필터에서는 DispatcherServlet의 빈에 직접적으로 접근할 수 없다. 그러나 Spring Security의 SecurityFilterChain을 사용하는 경우에는 DispatcherServlet의 빈에 접근할 수 있다.

Spring Security는 내부적으로 DispatcherServlet과 연동하여 보안 관련 작업을 처리하기 때문에, 필터 체인을 통과한 후에 DispatcherServlet의 빈에 접근할 수 있다. 스프링 시큐리티와 DispatcherServlet 간에는 위임이 필요하며, SecurityFilterChain을 통해 이러한 위임이 이루어진다.

(chain이라는 말은 여러 개의 연결고리라는 뜻인데, 필터를 여러 가지 등록하는 것을 chain을 따라 인증을 진행한다고 생각하면 된다.)

개발자가 spring security를 해서 구현하는 방법이 여러 가지이다. filter 자체를 이해해서 filter를 구현하는 방법이 있고, 필터에서 돌아가는 여러 가지 함수 메소드들을 오버라이딩해서 일부를 커스터마이징할 수도 있다. (나는 일부 흐름만 커스터마이징하였다.)

JWT

JWT는 JSON Web Token의 약자이다. 정보를 JSON 형태로 전송하는 토큰이라는 의미이다. JWT는 URL로 이용할 수 있는 문자열로만 구성되어 있고 서버와의 통신에서 사용된다.

JWT의 구조

• 헤더(Header) : 검증과 관련된 내용, 해싱 알고리즘과 토큰 타입 지정
• 내용(Payload) : 토큰에 담는 정보. 여기에 포함된 속성들은 클레임이라고 한다.
• 서명(Signature) : 인코딩된 헤더, 인코딩된 내용, 비밀키, 헤더의 알고리즘으로 서명이 생성됨.

https://jwt.io/#debugger-io
여기에 들어가면 JWT를 생성할 수 있고 디코딩된 정보도 볼 수 있다.

스프링 시큐리티와 JWT 적용하기

UsernamePasswordAuthenticationFilter를 통한 인증 과정

1. 클라이언트가 사용자의 아이디와 비밀번호를 포함한 인증 요청을 서버로 전송한다.
2. 요청을 받게 되면 서블릿 필터에서 SecurityFilterChain으로 작업이 위임된다. (DispatcherServlet의 bean에 접근하기 위해)
3. SecurityFilterChain 중에서 AuthenticationFilter에서 인증을 처리한다. 아무 설정하지 않았으면 AuthenticationFilter 중에서 UsernamePasswordAuthenticationFilter가 인증을 처리한다.
4. AuthenticationFilter는 요청받은 username이랑 password를 가지고 UsernamePasswordAuthenticationToken에서 토큰을 생성한다.
5. 그러면 만든 토큰을 AuthenticationManager에게 전달한다. AuthenticationManager는 인터페이스이고 이를 구현한 것은 ProvideManager이다.
6. ProvideManager는 인증을 해주어야 하기 때문에 AuthenticationProvider로 토큰을 전달한다. 해당 Provider에서 인증을 수행하고 성공하게 되면 ProvideManager로 권한을 담은 토큰을 전달한다.
7. AuthenticationProvider는 UserDetailsService에 토큰의 정보를 전달한다.
8. UserDetailsService는 전달받은 정보를 통해 데이터베이스에서 일치하는 사용자를 찾아서 UserDetails 객체를 생성한다
9. 생성된 UserDetails객체는 다시 AuthenticationProvider로 전달되고, Provider에서 인증이 성공하면 ProviderManager로 권한을 담은 토큰을 전달하게 된다.
10. 그럼 ProviderManager는 다시 검증된 토큰을 AuthenticationFilter로 전달한다.
11. AuthenticationFilter는 토큰을 SecurityContextHolder에 있는 SecurityContext에 저장한다.

UsernamePasswordAuthenticationFilter는 접근 권한을 확인하고 인증이 실패할 경우 화면을 보내는 역할을 한다.

이전에 SpringSecurity와의 변경점(feat. WebSecurityConfigureAdapter 상속받는 방법 없어짐)

스프링 공식문서에 나와있는 JWT 적용방식을 응용하여서 구현해보겠다. JWT 샘플코드는 아래의 것을 사용하였다.
https://github.com/spring-projects/spring-security-samples/tree/main/servlet/spring-boot/java/jwt/login

SecurityConfiguration 구현

일단 책이랑 정보를 찾아보았을 때 WebSecurityConfigureAdapter를 상속받아서 스프링 시큐리티를 설정한다고 하였으나 실제로 IntelliJ에서 해당 클래스가 deprecated되어서 현재는 위의 document를 응용해서 구현하였다. (Security 5.7부터 바뀌었다고 한다)
Spring Blog에도 해당 내용이 나와있다.
https://spring.io/blog/2022/02/21/spring-security-without-the-websecurityconfigureradapter
(기존에는 WebSecurityConfigurerAdapter를 상속받아 설정을 오버라이딩 하는 방식이었는데 바뀐 방식에서는 상속받아 오버라이딩하지 않고 모두 Bean으로 등록을 한다.)

document에서는 authorize.anyRequest().authentication()으로 되어있다. 그렇게 되면 로그인 하지 않으면, 권한이 없으므로 login 페이지로 계속 이동하기 때문에 일단 permitAll()을 해놓고 login 페이지가 잘 보이는 것을 확인하고 구현을 시작하였다. 공식문서의 SecurityConfig 페이지는 아래와 같고, 여기서 rule을 추가시키겠다.

@Configuration  
public class SecurityConfig {  
    @Bean  
    public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {  
    http  
        .authorizeHttpRequests((authorize) -> authorize  
        .anyRequest().permitAll()  
    )  
        .httpBasic(withDefaults())  
        .formLogin(withDefaults());  
    return http.build();  
    }  
}

Rule 추가하기

위의 코드에서는 anyRequest()가 되어 있어서 어떤 url이든 인증이 필요하다. anyRequest()를 mvcMatchers()(아니면 antMatchers사용)를 사용하고 안에 parameter로 url을 넣을수도 있고, 아니면 HTTPMethod중 GET이나 POST 같은 것들로 지정해줄 수도 있다. 로그인과 회원가입, swagger 문서들은 jwt 토큰이 있을 수가 없다. 그래서 해당 url은 인증의 범위에서 제외시켜주었다.

// SecurityConfig
@Configuration
@EnableWebSecurity
@RequiredArgsConstructor
public class SecurityConfig {

    private final JwtTokenProvider jwtTokenProvider;

    @Bean
    public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
        http
                .httpBasic().disable()
                .csrf().disable()
                .sessionManagement().sessionCreationPolicy(SessionCreationPolicy.STATELESS)
                .and()
                .authorizeRequests()
                .antMatchers("/members/login").permitAll()
                .antMatchers("/members/signup").permitAll()
                .antMatchers("/members/check").permitAll()
                .antMatchers("/swagger-ui/index.html").permitAll()
                .anyRequest().authenticated()
                .and()
                    .addFilterBefore(new JwtAuthenticationFilter(jwtTokenProvider), UsernamePasswordAuthenticationFilter.class);
        return http.build();
    }

    @Bean
    public PasswordEncoder passwordEncoder() {
        return PasswordEncoderFactories.createDelegatingPasswordEncoder();
    }
}

• httpBasic().disable() : Spring Securtiy를 처음 의존성을 추가하면 BASE64를 이용하여 비밀번호가 나온다(https://jobdong7757.tistory.com/205 참고) 그걸 disable하는 내용이다. (사용안하고 jwt 사용할 거니까)
• csrf().disalbe() : 쿠키 기반이 아니라 jwt 기반이므로 사용하지 않는다
• `sessionManagement().sessionCreationPolicy(SessionCreationPolicy.STATELESS) : Spring Security 세션 정책 : 세션을 생성 및 사용하지 않는다.
• antMatchers({허용할 endpoint}) : 여기에는 인증이 필요없는 endpoint를 작성해서 permitAll() 해주면 된다.
• addFilterBefore(new JwtAuthenticationFilter(jwtTokenProvider), UsernamePasswordAuthenticationFilter.class) : JWT 인증 필터를 UsernamePasswordAuthenticationFilter.class 앞에 적용하겠다는 의미로 jwtTokenProvider를 이후에 작성할 예정이다.

PasswordEncoder

PasswordEncoder는 스프링 시큐리티에서 비밀번호를 안전하게 저장하고 검증하기 위해 사용되는 인터페이스이다. PasswordEncoder를 구현한 구체적인 클래스는 비밀번호를 해싱하고, 솔트(salt)를 적용한다.

PasswordEncoderFactories.createDelegatingPasswordEncoder()는 스프링 시큐리티에서 제공하는 PasswordEncoder의 구현체를 생성하는 메서드이다. 이 메서드는 현재 스프링 시큐리티의 기본 비밀번호 인코더를 생성하고 반환한다.

주로 사용자의 비밀번호를 저장하기 전에 해당 비밀번호를 해싱하여 안전하게 저장하고, 로그인 시 비밀번호를 검증하는 등의 작업에 PasswordEncoder를 사용할 수 있다.

jwt 토큰과 jwt 인증 필터를 어떻게 사용하면 될까

jwt 토큰을 어떻게 사용할지 정리해보겠다. (이메일을 아이디처럼 사용할 것이다. 회원의 데이터베이스에 id로 저장되는 것과 다른 것이다.)
먼저, 회원가입을 할 때는 이메일과 비밀번호만 받으면 된다. 해당 정보를 입력하였을 때, 나는 회원가입이 성공하면 id, 이메일, 생성시간 3가지를 전달받는다.

그리고 로그인을 할 때는 이메일, 비밀번호를 입력하면 된다. 그럼 나는 반환 값으로 이메일, grantType(여기서는 Bearer), accessToken, refreshToken같은 인증 토큰을 전달받으면 된다.

그럼 이후부터 api 요청을 할 때, accessToken을 header에 넣어서 보내야 api가 요청이 되게 한다. 그 의미는 인증된 사용자라는 뜻이기 때문이다.

accessToken과 refreshToken을 따로 두는 것은, accessToken이 탈취될 위험이 있기 때문에, accessToken의 기한을 짧게 두고 해당 기한이 만료되면 새로 발급받기 위해 기한이 긴 refresToken을 이용해서 새로 발급받으면 되기 때문이다.

그럼 하나하나 구현을 해보겠다.

Member Controller 구성

먼저 로그인이랑 회원가입을 할 수 있도록 controller를 구성한 다음, service를 구현할 생각을 하였다. (맨 처음에 적용할 endpoint 적용)

@RestController
@RequiredArgsConstructor
@RequestMapping("/members")
public class MemberController {
    private final MemberService memberService;

    @PostMapping("/login")
    @ResponseStatus(HttpStatus.ACCEPTED)
    public MemberLoginResponseDto login(@RequestBody MemberLoginRequestDto memberLoginRequestDto) {
        String email = memberLoginRequestDto.getEmail();
        String password = memberLoginRequestDto.getPassword();
        return memberService.login(email, password);
    }

    @PostMapping("/signup")
    @ResponseStatus(HttpStatus.CREATED)
    public MemberSignUpResponseDto signup(@Valid @RequestBody MemberSignUpRequestDto memberSignUpRequestDto) {
        String email = memberSignUpRequestDto.getEmail();
        String password = memberSignUpRequestDto.getPassword();
        return memberService.signup(email, password);
    }

    @GetMapping("/check")
    @ResponseStatus(HttpStatus.OK)
    public MemberSignUpResponseDto checkMember(HttpServletRequest request) {
        return memberService.checkMember(request);
    }

}

회원가입

회원가입을 먼저 구현해 보겠다. 위의 controller에서 memberService의 signup함수를 구현하면 된다.
일단 중복 이메일을 체크해야 하므로, 중복된 이메일을 처리해주었다. 그리고 아직은 role에 대한 것을 해야할 요구조건이 없으므로 Role은 USER로 저장해주었다. (그럼 모든 권한이 가능하게 아래에서 처리하게 하였다.)

// MemberService의 signup 함수
    @Transactional
    public MemberSignUpResponseDto signup(String email, String password) {
        // 중복된 이메일 체크
        if (memberRepository.findByEmail(email).isPresent()) {
            throw new RuntimeException("중복된 이메일이 존재합니다");
        }
        Member member = Member.builder()
                .email(email)
                .password(password)
                .createdAt(LocalDateTime.now())
                .updatedAt(LocalDateTime.now())
                .build();
        Member savedMember = memberRepository.save(member);
        MemberSignUpResponseDto responseDto = new MemberSignUpResponseDto(savedMember.getId(), savedMember.getEmail(), savedMember.getCreatedAt());
        return responseDto;
    }

먼저 중복된 이메일을 체크하고, Member 도메인의 builder 패턴으로 입력받은 이메일과 비밀번호로 만들어준다.

@Getter
@Builder
@NoArgsConstructor
@AllArgsConstructor
@Entity
public class Member extends BaseEntity {
    @Id @Column(updatable = false, unique = true, nullable = false, length = 250)
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    @Column(nullable = false, length = 100)
    private String email;

    @Column(nullable = false, length = 250)
    private String password;

    @CreatedDate
    @DateTimeFormat(iso = DateTimeFormat.ISO.DATE_TIME)
    LocalDateTime createdAt;

    @LastModifiedDate
    @DateTimeFormat(iso = DateTimeFormat.ISO.DATE_TIME)
    LocalDateTime updatedAt;

    @Builder
    public Member(String email, String password, LocalDateTime createdAt, LocalDateTime updatedAt) {
        this.email = email;
        this.password = password;
        this.createdAt = createdAt;
        this.updatedAt = updatedAt;
    }
}

UserDetails
UserDetails 인터페이스는 스프링 시큐리티에서 사용자의 정보와 권한을 제공하기 위한 인터페이스이다. 사용자의 인증과 권한 부여를 처리하는 과정에서 스프링 시큐리티가 UserDetails 객체를 통해 사용자 정보를 관리하고 제공한다. (하지만, 현재로서는 권한을 부여할 필요는 없어서 해당 내용은 제외하였다.)

UserDetails 인터페이스는 다음과 같은 주요 메서드를 정의하고 있다.

1. getUsername(): 사용자의 고유한 식별자인 사용자 이름을 반환
2. getPassword(): 사용자의 비밀번호를 반환
3. getAuthorities(): 사용자의 권한 목록을 반환. 각 권한은 GrantedAuthority 인터페이스를 구현한 객체로 표현된다.
4. isAccountNonExpired(): 사용자 계정의 유효 기간이 만료되었는지 여부를 반환
5. isAccountNonLocked(): 사용자 계정이 잠겨있는지 여부를 반환
6. isCredentialsNonExpired(): 사용자의 인증 정보(비밀번호)의 유효 기간이 만료되었는지 여부를 반환
7. isEnabled(): 사용자 계정이 활성화되었는지 여부를 반환

UserDetails 인터페이스를 통해 애플리케이션에서 보안 관련 작업을 보다 쉽게 구현할 수 있다.

로그인 구현하기

로그인은 이메일과 비밀번호를 받으면 인증을 처리하고 jwt token을 만들어주어야 하기 때문에 처음 배우는 부분이 많았다. 하나하나 차례대로 보겠다.

MemberService에 있는 login함수

@Transactional  
public MemberLoginResponseDto login(String email, String password) {  
    // 1. Login ID/PW 를 기반으로 Authentication 객체 생성  
    // 이때 authentication 는 인증 여부를 확인하는 authenticated 값이 false
    UsernamePasswordAuthenticationToken authenticationToken = new UsernamePasswordAuthenticationToken(email, password);  

    // 2. 실제 검증 (사용자 비밀번호 체크)이 이루어지는 부분  
    // authenticate 매서드가 실행될 때 CustomUserDetailsService 에서 만든 loadUserByUsername 메서드가 실행  
    Authentication authentication = authenticationManagerBuilder.getObject().authenticate(authenticationToken);  

    // 3. 인증 정보를 기반으로 JWT 토큰 생성  
    TokenInfo tokenInfo = jwtTokenProvider.generateToken(authentication);  

    return new MemberLoginResponseDto(email, tokenInfo.getGrantType(), tokenInfo.getAccessToken(), tokenInfo.getRefreshToken());  
}

• UsernamePasswordAuthenticationToken authenticationToken = new UsernamePasswordAuthenticationToken(email, password) : UsernamePasswordAuthenticationToken 객체는 사용자의 인증 정보를 담고 있으며, 인증 매니저에게 전달하여 실제로 사용자를 인증하는 과정에서 사용된다.
• Authentication authentication = authenticationManagerBuilder.getObject().authenticate(authenticationToken); :
  AuthenticationFilter는 생성한 authenticationToken AuthenticationManager에게 전달한다. AuthenticationManager은 실제로 인증을 처리할 여러개의 AuthenticationProvider를 가지고 있다. 그럼 UserDetailService에서 해당 내용을 기반으로 조회를 한다.

UsernamePasswordAuthenticationToken 클래스
UsernamePasswordAuthenticationToken은 스프링 시큐리티에서 사용자의 인증을 처리할 때 사용되는 객체이다. 주로 사용자가 제출한 아이디(여기서는 email)와 비밀번호(password) 정보를 포함하여 인증 작업에 필요한 정보를 전달하는 데 사용된다.

UsernamePasswordAuthenticationToken은 인증 매커니즘에서 인증을 수행하는 과정에서 생성되고 사용된다. 일반적으로 사용자가 로그인 페이지에서 사용자 이름과 비밀번호를 입력하면, 스프링 시큐리티는 UsernamePasswordAuthenticationToken 객체를 생성하여 사용자가 제출한 인증 정보를 담아 인증 처리를 시작한다.

UsernamePasswordAuthenticationToken은 Authentication 인터페이스를 구현한 클래스로, 사용자의 인증 정보를 담고 있다. Authentication은 스프링 시큐리티에서 인증에 필요한 정보를 캡슐화하는 인터페이스이다.

UsernamePasswordAuthenticationToken은 주로 AuthenticationManager에 의해 처리되며, 인증 과정에서 제공된 사용자 이름과 비밀번호를 사용하여 사용자를 인증한다. 인증이 성공하면 Authentication 객체가 인증된 상태로 반환되고, 인증 실패시에는 예외가 발생할 수 있다.

CustomUserDetailsService

@Service
@RequiredArgsConstructor
public class CustomUserDetailsService implements UserDetailsService {

    private final MemberRepository memberRepository;
    private final PasswordEncoder passwordEncoder;

    @Override
    public UserDetails loadUserByUsername(String email) throws RuntimeException {
        return memberRepository.findByEmail(email)
                .map(this::createUserDetails)
                .orElseThrow(() -> new RuntimeException("해당하는 유저를 찾을 수 없습니다."));
    }

    // 해당하는 User 의 데이터가 존재한다면 UserDetails 객체로 만들어서 리턴
    private UserDetails createUserDetails(Member member) {
        return User.builder()
                .username(member.getEmail())
                .password(passwordEncoder.encode(member.getPassword()))
                .build();
    }
}

CustomUserDetailsService 클래스가 Authentication authentication = authenticationManagerBuilder.getObject().authenticate(authenticationToken); 에서 동작되는 원리

1. AuthenticationManager는 인증 요청에 필요한 사용자 정보를 DB에서 가져와야 한다. 이때 loadUserByUsername 메서드가 호출된다.
2. loadUserByUsername 메서드는 UserDetailsService 인터페이스를 구현한 CustomUserDetailsService에서 구현된다. 해당 메서드는 주어진 사용자 이름(username)을 기반으로 사용자 정보를 조회하고, UserDetails 객체를 반환한다.
3. AuthenticationManager는 loadUserByUsername 메서드를 통해 반환된 UserDetails 객체를 사용하여 인증 과정을 진행한다. 인증 과정에서는 사용자가 입력한 인증 정보와 UserDetails 객체에 저장된 정보를 비교하여 인증을 수행한다.
4. AuthenticationManager는 인증 결과인 Authentication 객체를 생성하여 반환한다. 이때 Authentication 객체는 인증된 사용자 정보와 권한 정보를 포함한다.

이제 DB에 사용자가 있다는 사실을 인증받은 것이므로 해당 내용을 바탕으로 jwtToken을 생성하는 jwtTokenprovider를 만들면 된다.

토큰 정보 클래스 만들기

클라이언트가 요청하면 서버는 jwt token을 클라이언트에게 response로 주어야 한다.
해당 정보를 클래스로 만들어보자.

@Builder  
@Data  
@AllArgsConstructor  
public class TokenInfo {  
    private String grantType;  // Bearer
    private String accessToken;  
    private String refreshToken;  
}

grantType
grant typedms 클라이언트가 어떤 유형의 인증 흐름을 사용하여 액세스 토큰을 요청하는지 나타낸다.
그 중에서 Bearer를 사용할 건데, Bearer 토큰은 서버에 상태를 저장하지 않고, 클라이언트가 요청을 보낼 때마다 토큰의 유효성을 검증한다. 그래서 이후에 HTTP 요청을 보낼때 헤더에 붙여서 보내면 인증된 사용자인지 검증할 수 있는 것이다.

JwtTokenProvider 클래스

JwtTokenProvider는 사용자 인증과 인가를 처리하는 데 사용되는 클래스이다. JWT (JSON Web Token)을 생성, 유효성 검사 및 해석하는 데 사용되고, 주로 Spring Security와 함께 사용되며, 사용자의 인증 정보를 JWT 토큰으로 인코딩하여 전달하고, 토큰의 유효성을 검사하여 사용자를 인증하고 권한을 부여한다. secret key를 사용해서 jwt token을 만들 것이다.

yml 파일에 secret key 추가

토큰을 암호화하고 복호화할 때 HS256 알고리즘을 사용하려면 secret key를 설정해주어야 한다. 해당 코드를 yml 파일에 적어주자. (아무거나 해당 길이만 맞으면 된다!)

jwt:  
    secret: VlwEyVBsYt9V7zq57TejMnVUyzblYcfPQye08f7MGVA9XkHa

JwtTokenProvider 클래스

// 토큰 생성  
@Slf4j
@Component
public class JwtTokenProvider {

    private final Key key;

    @Value("${jwt.secret}")
    String salt;

    private final long at_exp = 1000L * 60 * 30;
    private final long rt_exp = 1000L & 60 * 60;
    // secret key를 가지고 key값 저장
    public JwtTokenProvider(@Value("${jwt.secret}") String salt) {
        this.key = Keys.hmacShaKeyFor(salt.getBytes(StandardCharsets.UTF_8));
    }

    // 토큰 생성
    public TokenInfo generateToken(Member member) {
        // Access Token 생성
        Claims claims = Jwts.claims().setSubject(member.getEmail());
        claims.put("memberId", member.getId());

        long now = (new Date()).getTime();
        Date accessTokenExpiresIn = new Date(now + at_exp);
        String accessToken = Jwts.builder()
                .setClaims(claims)
                .setExpiration(accessTokenExpiresIn)
                .signWith(key, SignatureAlgorithm.HS256)
                .compact();

        // Refresh Token 생성
        String refreshToken = Jwts.builder()
                .setExpiration(new Date(now + rt_exp))
                .signWith(key, SignatureAlgorithm.HS256)
                .compact();

        return TokenInfo.builder()
                .grantType("Bearer")
                .accessToken(accessToken)
                .refreshToken(refreshToken)
                .build();
    }

    // JWT 토큰을 복호화하여 토큰에 들어있는 정보를 꺼내는 메서드
    public Authentication getAuthentication(String accessToken) {
        // 토큰 복호화
        Claims claims = parseClaims(accessToken);

        // UserDetails 객체를 만들어서 Authentication 리턴
        UserDetails principal = new User(claims.getSubject(), "", Collections.emptyList());
        return new UsernamePasswordAuthenticationToken(principal, "", Collections.emptyList());
    }

    // 토큰 정보를 검증하는 메서드
    public boolean validateToken(String token) {
        try {
            Jwts.parserBuilder().setSigningKey(key).build().parseClaimsJws(token);
            return true;
        } catch (RuntimeException e) {
            throw e;
        }

    }

    private Claims parseClaims(String accessToken) {
        try {
            return Jwts.parserBuilder().setSigningKey(key).build().parseClaimsJws(accessToken).getBody();
        } catch (RuntimeException e) {
            throw e;
        }
    }

    // Bearer 제외부분
    public String getToken(String token) {
        token = token.substring(7).trim();
        return token;
    }

    public String getEmail(String token) {
        return Jwts.parserBuilder().setSigningKey(salt.getBytes()).build().parseClaimsJws(token).getBody().getSubject();
    }

    public String resolveToken(HttpServletRequest request) {
        return request.getHeader("Authorization");
    }
}

1. authentication.getAuthorities()를 통해 사용자의 권한 정보를 가져온다. 권한은 GrantedAuthority 객체로 표현되며, getAuthority()를 사용하여 권한 이름을 추출한다. 여러 권한이 있을 경우 쉼표로 구분하여 문자열로 합친다.
2. 현재 시간을 기준으로 액세스 토큰의 만료 시간을 계산한다. new Date(now + ac_exp)를 통해 현재 시간으로부터 30분 후의 시간을 나타내는 accessTokenExpiresIn을 생성한다.
3. Jwts.builder()를 사용하여 JWT 빌더를 생성한다. setSubject(authentication.getName())로 JWT의 subject(주체)를 사용자명으로 설정한다. 권한은 필요없으므로 empty로 둔다.
4. setExpiration(accessTokenExpiresIn)으로 액세스 토큰의 만료 시간을 설정한다. signWith(key, SignatureAlgorithm.HS256)로 시크릿 키와 알고리즘을 사용하여 토큰을 서명한다. compact()를 호출하여 토큰을 문자열로 변환한다.
5. refreshToken을 생성한다. 액세스 토큰과 동일한 방식으로 빌더를 생성하고, 만료 시간을 현재 시간으로부터 24시간 후로 설정한다.
6. TokenInfo 객체를 생성하고, grantType을 "Bearer"로 설정하고, 생성된 액세스 토큰과 리프레시 토큰을 할당한다.

이 코드는 사용자의 인증 정보를 JWT 토큰으로 변환하여 반환하는 메서드로, 액세스 토큰과 리프레시 토큰을 생성하여 TokenInfo 객체로 래핑하여 반환한다.

JwtAuthenticationFilter

JWT 인증을 하기 위해 사용되는 필터로 JwtAuthenticationFilter를 통과하고 UsernamePasswordAuthenticationFilter를 진행하게 된다.
해당 과정은 토큰이 유효한지 검사하고 토큰 정보를 추출하는 함수이다.

@RequiredArgsConstructor
public class JwtAuthenticationFilter extends GenericFilterBean {

    private final JwtTokenProvider jwtTokenProvider;

    @Override
    public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {
        // 1. Request Header 에서 JWT 토큰 추출
        String token = resolveToken((HttpServletRequest) request);

        // 2. validateToken 으로 토큰 유효성 검사
        if (token != null && jwtTokenProvider.validateToken(token)) {
            // 토큰이 유효할 경우 토큰에서 Authentication 객체를 가지고 와서 SecurityContext 에 저장
            Authentication authentication = jwtTokenProvider.getAuthentication(token);
            SecurityContextHolder.getContext().setAuthentication(authentication);
        }
        chain.doFilter(request, response);
    }

    // Request Header 에서 토큰 정보 추출
    private String resolveToken(HttpServletRequest request) {
        String bearerToken = request.getHeader("Authorization");
        if (StringUtils.hasText(bearerToken) && bearerToken.startsWith("Bearer")) {
            return bearerToken.substring(7);
        }
        return null;
    }
}

먼저 아래와 같은 내용으로 spring project를 하나 만들어주었다.

해당 애플리케이션을 실행하면 콘솔창에 아래와 같은 내용이 나온다. 해당 정보를 복사하여, id에는 user를 입력하고 로그인할 수 있다.

처음 애플리케이션이 실행되면 Spring Security는 Bean 중에서 type이 SecurityFilterChain인 것을 찾는다.

SecurityFilterChain을 한번 살펴보겠다.

SecurityFilterChain은 springframework.security.web의 것이고, 이것은 인터페이스이므로 스프링 bean 선언으로 이동하자.

interface 옆에 아이콘을 클릭하면 이동할 수 있다.

defaultSecurityFilterChain이라고 되어 있다. 매개변수로는 HTTPSecurity를 받고 여기서는 http.authorizeRequests()로 모든 Request는 인증되어야한다고 되어있다. 그래서 위의 화면처럼 우리는 로그인 화면에서 비밀번호를 입력해야 다른 화면으로 넘어갈 수 있는 것이다. formLogin은 Spring Security에서 기본적으로 제공해주는 로그인 화면이다. (아까 본 화면)

스프링으로 모든 endpoint를 자동으로 보호하기 때문에 우리가 Endpoint에 직접 접근이 불가능했던 이유이다.

(HttpBasic은 formlogin이 작동하지 않을 경우를 위해서 만든 라인이다.)

이후에 jwt 토큰을 사용하여 로그인하는 글을 포스팅해보겠다.

보안 용어

인증(authentication)

인증(authentication)은 사용자가 누구인지 확인하는 단계이고 보통 로그인을 의미한다.
사용자는 아이디와 패스워드를 입력하면 로그인은 데이터베이스에 등록되어있는지 일치 여부를 확인하고, 서버는 응답으로 사용자에게 토큰(token)을 전달한다.

인가(authorization)

인가(authorization)은 사용자가 애플리케이션 내부의 리소스에 접근할 때 사용자가 해당 리소스에 접근할 권리가 있는지를 확인하는 과정을 의미한다. 로그인한 사용자가 게시판에 접근해서 글을 보려고 하는 경우 게시판 접근 등급을 확인해서 접근을 허가하거나 거부하는 것이 인가이다.
인증 단계에서 발급받은 토큰이 인가 내용을 포함하고 있으며, 사용자가 리소스에 접근하면서 토큰을 함께 전달하는 식으로 진행하여 서버는 토큰을 통해 권한 유무 등을 확인해서 인가를 수행한다.

접근 주체(principal)

접근 주체는 애플리케이션 기능을 사용하는 주체를 의미한다. 인증과 인과 과정을 거쳐서 접근 주체에게 부여된 권한을 확인하는 과정을 거친다.

스프링 시큐리티 (Spring Security)

스프링 시큐리티도 일종의 보안 프레임워크이기 때문에 공부가 필요했다.

동작 구조

스프링 시큐리티는 서블릿 필터(Servlet Filter)를 기반으로 동작하며, 스프링이 가지는 서블릿 컨테이너인 DispatcherServlet 앞에, 필터가 배치되어 있다.

필터체인이라는 것이 Dispatcher Servlet 앞에 존재해서 클라이언트가 request를 보내면 먼저 맞닥뜨리게 된다.

필터체인

필터 체인(Filter Chain)은 웹 애플리케이션에서 요청을 처리하는 과정에서 여러 개의 필터가 순차적으로 실행되는 구조를 말한다. 필터 체인은 클라이언트로부터의 요청이 서블릿에 도달하기 전과 응답이 클라이언트에게 전달되기 전에 요청과 응답을 가공하거나 검증하는 역할을 수행한다.

필터 체인 동작 순서

클라이언트로부터의 요청이 서블릿 컨테이너에 도달하면, 요청은 필터 체인의 시작 지점인 필터 체인의 진입점으로 전달되어서 필터 체인의 첫 번째 필터부터 순차적으로 실행된다. 마지막 필터가 실행되고 나면 요청이 서블릿에 도착해서 실제 작업을 수행하고 응답도 똑같이 필터 체인의 뒤에서부터 전달된다.

스프링 시큐리티의 사용 이유

ApplicationFilterChain은 서블릿 컨테이너에서 기본적으로 제공되는 필터 체인의 구현이다. 물론, Spring Security를 사용하지 않고도 ApplicationFilterChain을 통해 보안과 관련된 인증과 인가를 처리할 수 있다. 

 보안과 관련된 인증과 인가 작업은 일반적으로 서블릿 필터를 사용하여 처리할 수 있다. 예를 들어, 사용자의 인증 정보를 확인하고 세션 관리를 수행하는 필터를 구현하여 인증 작업을 처리할 수 있다. 또한, 요청에 따라 특정 리소스에 대한 접근 권한을 확인하는 필터를 구현하여 인가 작업을 처리할 수도 있다.

ApplicationFilterChain은 필터 체인 내에서 필터들을 연결하여 원하는 순서로 실행할 수 있기 때문에, 보안 관련 필터들을 적절히 구성하면 보안 요구사항을 처리할 수 있지만 직접 필터를 구현하고 관리해야 한다는 점에서 Spring Security와 비교하면 개발 및 유지보수의 복잡성이 높아질 수 있기 때문에 Spring Security를 사용하게 된다. (프레임워크의 장점!)

Spring Security는 보안에 특화된 기능과 설정을 제공하여 보다 쉽고 강력한 보안 솔루션을 제공한다. Spring Security를 사용하면 인증, 인가, 세션 관리, CSRF 방어, XSS 방어 등의 보안 기능을 편리하게 구현하고 관리할 수 있다.

그래서 스프링 프레임워크에서 필터 체인을 활용하여 다양한 기능을 구현할 수 있으며, Spring Security의 SecurityFilterChain은 그 중 하나의 예이다.

두 FilterChain은 서로 다른 목적을 가지고 있다. ApplicationFilterChain은 서블릿 컨테이너에서 일반적인 필터 체인을 관리하고 실행하는 역할을 수행하며, SpringFilterChain은 Spring Security에서 보안 관련 필터 체인을 관리하고 실행하는 역할을 수행하게 된다.

스프링 시큐리티 동작

클라이언트가 애플리케이션에 request를 보내면 서블릿 컨테이너가 필터와 서블릿을 매칭해버린다. 스프링 시큐리티는 사용하고자 하는 필터체인을 서블릿 컨테이너의 필터 사이에서 동작시키기 위해 DelegatingFilterProxy를 사용한다.

DelegatingFilterProxy는 서블릿 컨테이너의 생명주기와 스프링 애플리케이션 컨텍스트 사이에서 다리 역할을 수행하는 필터 구현체이다. 표준 서블릿 필터를 구현하고 있으며, 역할을 위임할 필터체인 프록시를 내부에 가지고 있다. 필터체인 프록시는 스프링부트의 자동 설정에 의해 자동 생성된다.

DelegatingFilterProxy

DelegatingFilterProxy는 Spring Framework에서 제공하는 필터의 대리자(Delegate) 역할을 수행하는 클래스이다.

일반적으로 서블릿 필터(Filter)는 서블릿 컨테이너에서 직접 관리된다. 근데, Spring Framework에서는 DelegatingFilterProxy를 사용하여 필터의 관리를 Spring의 ApplicationContext로 위임할 수 있다.
(위임의 이유는 스프링의 의존성 주입할 수 있고, 스프링의 여러 기능을 사용할 수 있기 때문이다)

DelegatingFilterProxy를 사용하면 이후에 클라이언트의 요청이 들어오면 DelegatingFilterProxy가 요청을 가로채서 등록된 필터 빈(Bean)을 찾아서 실행한다.

즉, DelegatingFilterProxy는 서블릿 필터의 대리자 역할을 수행하여 Spring ApplicationContext 내에서 등록된 필터 빈을 실행시키는 역할을 한다. 이를 통해 Spring의 의존성 주입(Dependency Injection)이 가능하며, 필터가 Spring 관리 빈으로 선언되어 다른 Spring 구성 요소와 함께 사용될 수 있게 되는 것이다. 

DelegatingFilterProxy는 Spring Security 필터 체인을 연결하는 데 사용된다. Spring Security에서는 보안 필터 체인을 구성하고, DelegatingFilterProxy를 통해 이를 등록하여 필터 체인을 관리하는 것이다.

필터체인 프록시는 스프링 시큐리티에서 제공하는 필터로서 보안 필터체인(SecurityFilterChain)을 통해 많은 보안 필터(Security Filter)를 사용할 수 있다. 필터체인 프록시에서 사용할 수 있는 보안 필터체인은 List 형식으로 담을 수 있게 설정되어있어서 URI 패턴에 따라 특정 보안필터 체인을 선택해서 사용하게 된다.

보안 필터체인에서 사용하는 필터는 여러가지가 있고, 필터마다 실행되는 순서가 다르다.
보안 필터체인은 WebSecurityConfigurerAdapter 클래스를 상속받아서 설정할 수 있다. 필터체인 프록시는 여러 보안 필터체인을 가질 수 있고, 여러 개의 보안 필터체인을 만들기 위해서는 WebSecurityConfigurerAdapter 클래스를 상속받는 클래스를 여러 개 생성하면 된다.

스프링 시큐리티에서는 디폴트로는 SecurityFilterChain에서 사용하는 필터 중 UsernamePasswordAuthenticationFilter를 통해 인증을 처리한다.

SecurityFilterChain
SecurityFilterChain은 보안 필터의 체인이다. Spring Security는 필터 기반 아키텍처를 사용하여 요청에 대한 인증 및 인가 작업을 처리한다. SecurityFilterChain은 다양한 필터를 포함하고 있으며, 각 필터는 특정한 보안 작업을 수행한다.

예를 들어, UsernamePasswordAuthenticationFilter는 사용자 이름/암호 인증을 처리하고, AccessDecisionManager는 권한 검사를 수행한다.

이제 개념적인 부분을 공부해보았으니 직접 구현을 하면서 로그인, 회원가입에 적용해봐야겠다.