* 이 글은 '스프링 부트와 AWS로 혼자 구현하는 웹 서비스' (프리렉, 이동욱 저)를 공부하며 내용을 정리한 글입니다.
* 이 글은 5. 스프링 시큐리티와 OAuth 2.0으로 로그인 기능 구현하기 (1)에서 이어집니다.
4. 어노테이션 기반으로 개선하기
일반적으로 프로그래밍을 할 때, 우리가 가장 피하고 싶은 상황 중에는 어느 것이 있을까?
각자 다른 상황이 떠오르겠지만, 같은 내용의 코드를 여러 번 반복해서 작성하는 상황은 많은 개발자들이 공감할 수 있을 것이다.
이런 상황에서는 작성을 여러 번 하며 귀찮기도 하지만, 나중에 이를 기능적으로 수정해야 할 때 반복해서 작성한 횟수만큼 고쳐야 한다. 뿐만 아니라 단순 오타 같은 문제가 생겨도 이를 찾아내기 쉽지 않다.
앞서 만든 코드 중에서 개선할 수 있는 부분은 무엇이 있을까?
앞서 작성한 IndexController에서 세션값을 가져오는 부분을 개선할 수 있다.
SessionUser user = (SessionUser) httpSession.getAttribute("user");index 메소드 외에 다른 controller와 메소드 외에서 세션값이 필요하면, 그때마다 직접 세션에서 값을 가져와야 한다. 즉 반복되는 코드인 것인데, 이를 매번 작성할 필요 없이 단순화하면 좋겠다.
이 부분을 메소드 인자로 바로 받을 수 있도록 변경해 보자.
config.auth 패키지에 아래와 같이 @LoginUser 어노테이션을 생성하자.
@Target은 이 어노테이션이 생성될 수 있는 위치를 지정하는 역할을 하는데, PARAMETER로 지정했으니 메소드의 파라미터로 선언된 객체에서만 사용할 수 있다. 그 외에 TYPE (클라스 선언문에 사용 가능) 등이 존재한다.
이어서 같은 위치에 LoginUserArgumentResolver를 생성한다. 이는 HandleMethodArguementResolver를 구현한 클라스이다.
첫 번째 Override인 supportsParameter는 controller 메서드의 특정 파라미터를 지원하는지 확인한다. 여기서는 파라미터에 @LoginUser 어노테이션이 붙어 있고, 파라미터 클라스 타입이 SessionUser.class인 경우 true를 return한다.
두 번째 Override인 resolveArgument는 파라미터에 전달할 객체를 생성하는 역할을 하는데, 여기서는 세션에서 객체를 가져오는 역할을 한다.
이로써 @LoginUser를 사용하기 위한 환경이 준비되었다. 다음으로, 이렇게 생성된 LoginUserArgumentResolver가 Spring에서 인식될 수 있도록, WebMvcConfigurer에 추가해 주자. config 패키지에 WebConfig 클라스를 생성하고, 아래와 같이 설정을 추가해 주자.
HandlerMethodArgumentResolver는 항상 WebMvcConfigurer의 addArgumentResolvers()를 통해 추가해야 한다. 이는 이후에 다른 HandlerMethodArgumentResolver가 필요하더라도 마찬가지로 추가해 주면 된다.
준비가 끝났으니, 이제 앞서 작성한 IndexController를 다시 열고, 반복되는 부분을 모두 @LoginUser 어노테이션으로 바꿔 주자.
index의 파라미터 부분에 새로 만든 @LoginUser를 추가해 주었다. 이제는 어느 컨트롤러든지 @LoginUser만 사용하면 세션 정보를 가져올 수 있다.
기능에 문제가 없음을 확인하는 것으로 @LoginUser로의 개선을 마무리하자.
5. 세션 저장소로 데이터베이스 사용하기
다음으로 우리가 만든 서비스의 개선점을 찾아보자.
현재 우리가 만든 웹사이트는 코드를 재실행하면 로그인이 풀린다. 이게 무슨 소리냐면, IDE에서 프로젝트를 실행하면 톰캣이 실행되고, localhost:8080을 통해 웹사이트에 접속할 수 있고, 이어서 Google 로그인이 가능하다.
하지만 IDE에서 실행 중지를 누르고, 다시 실행하면? 구동 중이었던 톰캣이 종료되었다가 다시 실행되고, 이후 다시 접속해 보면 Google 로그인이 풀려 있다. 이는 세션이 내장 톰캣의 메모리에 저장되기 때문이다.
기본적으로 세션은 실행되는 WAS의 메모리에서 저장되고 호출되는데, 이러다 보니 우리가 사용하는 내장 톰캣처럼 애플리케이션을 실행 시 실행되는 구조에서는 항상 초기화가 되는 것이다. 거기에, 배포할 때마다 톰캣이 재시작된다.
다른 문제가 하나 더 있다. 세션이 내장 톰캣의 메모리에 저장되고 있다면, 2대 이상의 서버에서 서비스를 제공하는 경우 톰캣마다 세션 동기화 설정을 해 주어야 한다.
따라서 실제 현업에서는 다음 세 가지 방법 중 하나를 선택한다.
- 톰캣 세션을 사용한다. 기본적인 방법으로, 위에서 언급한 대로 2대 이상의 WAS가 구동되는 환경에서는 톰캣들 간의 세션 공유를 위한 추가 설정이 필요하다.
- MySQL과 같은 DB를 세션 저장소로 사용한다. 여러 WAS 간의 공용 세션을 사용할 수 있는 가장 쉬운 방법이지만, 로그인 요청마다 DB IO가 발생하여 성능 이슈가 발생할 수 있다. 따라서 로그인 요청이 많이 없는 환경에서 유리하다.
- Redis, Memcached와 같은 메모리 DB를 세션 저장소로 사용한다. B2C 서비스에서 많이 사용하는 방식으로, 실제 서비스로 사용하기 위해서는 외부 메모리 서버가 필요하다.
우리는 두 번째 방식인 데이터베이스를 세션 저장소로 사용해 보도록 하자. 설정이 간단하고, 사용자가 많은 서비스가 아니며, 비용 절감을 기대할 수 있다. Redis와 같은 메모리 DB는 별도로 사용료를 지불해야 하므로, 서비스의 규모가 커지는 경우에 고려해 볼 법하다.
먼저, spring-session-jdbc를 등록하자. spring web, spring jpa와 마찬가지로, 의존성이 등록되어야 사용할 수 있다. build.gradle을 열고, 아래와 같이 의존성을 추가해 주자.
compile('org.springframework.session:spring-session-jdbc')그리고 application.properties에 세션 저장소를 jdbc로 선택하도록 코드를 한 줄 추가해 주면 된다.
spring.session.store-type=jdbc
이상으로 설정이 끝났다. 매우 간단하다!
하지만 지금 어플리케이션을 다시 시작해도 종료 후엔 모든 로그인이 풀릴 것이다. 현재 DB는 H2를 쓰고 있는데, 스프링이 재실행될 때 H2도 재실행되기 때문이다. 추후에 AWS로 배포할 때 AWS의 데이터베이스 서비스인 RDS를 사용하게 되면 이때부터는 세선이 풀리지 않는다.
H2 console에서 이를 미리 확인해 볼 수 있는데, 세션을 위한 테이블 2개가 생성된 것을 확인할 수 있다. JPA로 인해 세션 테이블이 자동으로 생성되었고, 이 테이블에 세션 정보가 저장될 것이다.
6. 네이버 로그인
이번에는 구글 로그인 외에, 네이버 로그인을 게시판에 추가해 보자.
가장 먼저 해야 할 일은 API 등록이다. https://developers.naver.com/apps/#/register?api=nvlogin
애플리케이션 - NAVER Developers
developers.naver.com
약관에 동의하고, 아래와 같이 각 항목을 채운다.
등록을 완료하면 다음과 같이 ClientID와 ClientSecret가 생성된다. Google 때와 같다. 중요 정보이므로 노출하지 않도록 하자.
위에서 얻은 키값을 application-oauth.properties에 등록하자. 네이버에서는 스프링 시큐리티를 공식 지원하지 않으므로, Google 때와는 다르게 OAuth2Provide가 해주던 값도 모두 직접 입력해야 한다.
한 눈에 봐도 구글 때보다 양이 많다.
맨 마지막 줄 (15번째 줄)을 보면, 기준의 되는 user-name의 이름을 네이버에서는 response로 하였다. 이는 네이버의 회원 조회 시 반환되는 JSON 형태 때문이다.
네이버 오픈 API의 로그인 회원 결과는 아래와 같다.
{
"resultcode": "00",
"message": "success",
"response": {
"email": "openapi@naver.com",
"nickname": "OpenAPI",
"profile_image": "https://ssl.pstatic.net/static/pwe/address/nodata_33x33.gif",
"age": "20-29",
"gender": "F",
"id": "12345678",
"name": "오픈 API",
"birthday": "10-01"
}
}스프링 시큐리티에서는 하위 필드를 명시할 수 없다. 최상위 필드들만 user_name으로 지정 가능한데, 네이버의 응답값 최상위 필드는 resultCode, message, response로 총 3개이다. 따라서 스프링 시큐리티에서 인식 가능한 필드를 저 3개 중에서 골라야 한다.
본문에서 담고 있는 response를 user_name으로 지정하고, 이후 Java 코드로 response의 ID를 user_name으로 지정하도록 하겠다.
앞서 구글 로그인을 등록하며 대부분의 코드를 확장성 있게 작성하였으므로, 네이버 로그인 기능 추가는 쉽게 가능하다.
OAuthAttributes에 다음과 같이 네이버인지 판단하는 코드와 네이버 생성자를 추가해 주면 된다.
위 내용만 추가하면 된다.
마지막으로 index.mustache를 수정하여, 접속 화면에 네이버 로그인 버튼을 하나 추가해 주자.
성공적으로 반영되었는지 확인해 보기 위해 다시 한 번 어플리케이션을 실행해 보자.
성공적으로 잘 추가되었다!
7. 기존 테스트에 시큐리티 적용하기
마지막으로 기존 테스트에 시큐리티 적용으로 문제가 되는 부분들을 해결해 보자.
시큐리티 적용에 대해 먼저 짚고 넘어가자. 기존에는 바로 API를 호출할 수 있어, 테스트 코드 역시 바로 API를 호출하도록 구성하였다. 하지만 시큐리티 적용이 되면, 즉 시큐리티 옵션이 활성화되면, 인증된 사용자만 API를 호출할 수 있다.
따라서 테스트 코드가 API를 호출할 수 없는 상황이 된다. 따라서 테스트 코드마다 인증한 사용자가 호출한 것처럼 작동하도록 수정해 보도록 하자.
IntelliJ 오른쪽 위에 Gradle 탭을 클릭하고, Tasks > verificiation > test를 차례로 선택하여 전체 테스트를 수행해 보자.
롬복을 이용한 테스트 외에, 스프링을 이용한 테스트는 모두 실패했다.
문제를 하나씩 찾아서 수정해 보자.
1. CustomOAuth2UserService를 찾을 수 없음
오류 메세지를 확인해 보면, "No qualifying bean of type 'org.example.springboot.config.auth.CustomOAuth2UserService" 라고 한다. CustomOAuth2UserService를 생성하는 데 필요한 소셜 로그인 관련 설정값들이 없기 때문이다.
아까 분명 application-oauth.properties에 설정값을 추가했는데, 왜 설정이 없다고 할까?
우리가 추가했던 환경은 src/main이었지만, 테스트는 src/test에서 이루어진다. src/main/resources/application.properties가 테스트 코드 수행 시에도 적용되는 이유는 test에 application.properties가 없으면 main의 것을 가져오기 때문인데, 이 때 자동으로 가져오는 범위는 application.properties 파일까지이다. 따라서 application-oauth.properties는 없다고 가져오는 파일이 아니다.
이를 해결하기 위해서 test에도 application.properties를 만들어 주자. 실제 구글까지 연동할 것은 아니므로 가짜 값을 넣어주면 된다.
이후 다시 그레이들로 테스트를 실행해 보면 해당 에러가 더 이상 발생하지 않는 것을 확인할 수 있다.
2. 302 Status Code
아래에 있는 "Posts_등록된다"의 테스트 로그를 확인해 보자.
정상 응답은 200인데, 실제로 받은 응답은 302라고 합니다. 302는 리다이렉션 응답을 뜻하는데, 스프링 시큐리티 설정에서는 인증되지 않은 사용자의 요청은 이동시키기 때문에 302를 얻었다. 따라서 이런 API 요청은 임의로 인증된 사용자를 추가하여 API만 테스트해 볼 수 있도록 해 보자.
스프링 시큐리티에서 공식적으로 방법을 지원하고 있다. spring-security-test를 build.gradle에 추가하자.
이어서 PostsApiControllerTest의 2개 테스트 메소드에 아래와 같이 임의 사용자 인증을 추가하자.
이렇게 해도 아직 작동하지 않는다. @WithMockUser는 MockMvc에서만 작동하는데, 현재 PostsApiControllerTest는 MockMvc를 전혀 사용하지 않는다.
@SpringBootTest에서 MockMvc를 사용하도록 바꾸어 보자.
다시 전체 테스트를 수행해 보자.
남은 에러가 2개로 줄었다.
3. @WebMvcTest에서 CustomOAuth2UserService를 찾을 수 없음
앞에서 해결한 것과 동일한 메세지인 "No qualifying bean of type ..." 를 얻게 된다. 이 문제가 발생한 배경은 앞에서와는 조금 다르다. 1번을 통해 스프링 시큐리티 설정은 잘 작동했지만, @WebMvcTest는 CustomOAuth2UserService를 스캔하지 않기 때문이다.
@WebMvcTest는 WebSecurityConfigurerAdapter, WebMvcConfigurer, @ControllerAdvice, @Controller를 읽는다. @Repository, @Service, @Component는 스캔 대상이 아니다. 그러니 CustomOAuth2UserService는 읽을 수가 없는 것이다.
다음과 같이 스캔 대상에서 SecurityConfig을 제거하자.
이렇게 한 후에 다시 테스트를 돌려 보자.
이번 에러는 @EnableJpaAuditing으로 인해 발생한다. @EnableJpaAuditing을 사용하기 위해서는 최소 하나의 @Entity 클라스가 필요한데, @WebMvcTest는 당연히 없다.
Application.java에서 @EnableJpaAuditing을 제거하도록 하자. 다음으로 config 패키지에 JpaConfig을 생성하고 @EnableJpaAuditing을 추가해 주자.
이후 다시 테스트를 실행해 보자.
모든 테스트를 통과하였다. 스프링 시큐리티 적용으로 깨졌던 테스트를 적절하게 수행할 수 있게 되었다.
여기까지 게시판을 완성하였다. 이후에는 AWS를 이용해 직접 배포하고 운영해 보도록 하겠다.
*이 글은 '스프링 부트와 AWS로 혼자 구현하는 웹 서비스' (프리렉, 이동욱 저)를 공부하며 내용을 정리한 글입니다.
'개발 > 스프링' 카테고리의 다른 글
| [혼자 구현하는 웹서비스] 7. AWS에 데이터베이스 환경을 만들어보자 - AWS RDS (0) | 2022.01.23 |
|---|---|
| [혼자 구현하는 웹서비스] 6. AWS 서버 환경을 만들어보자 - AWS EC2 (0) | 2022.01.16 |
| [혼자 구현하는 웹서비스] 5. 스프링 시큐리티와 OAuth 2.0으로 로그인 기능 구현하기 (1) (0) | 2021.12.31 |
| [혼자 구현하는 웹서비스] 4. 머스태치로 화면 구성하기 (0) | 2021.07.20 |
| [혼자 구현하는 웹서비스] 3. (2) JPA 테스트 코드 및 API 작성 (0) | 2021.07.09 |
댓글