1. 하얗게 불태웠어 로그아웃

프로젝트를 작성할 때 회원가입과 로그인, 로그아웃을 먼저 만들었는데, 로그아웃에서 제대로 안 되는 문제가 발생했다.

로그아웃이 왜 안되는가? 싶어서 계속 코드를 봤다.
저번처럼 토큰을 가져와서 로그아웃을 시도했으나 안 되었다.

그리고 결국 발견한 문제는 Fiter 부분에서 문제가 발생했다.
알고보는 스프링 시큐리티에서는 SecurityConfig 단에서 작동되게 해야했다.

        http
            .logout(logout -> logout
                .logoutUrl("/logout")
                .addLogoutHandler((request, response, authentication) -> {
                    토큰 불러오기

                    if (블랙리스트에 토큰이 이미 있으면)) {
                    토큰에 대한 예외처리 출력하고 종료
                    }

                    if (토큰이 null이 아니면) {
                        블랙리스트에 토큰 추가(로그아웃)
                    }
                })
                .logoutSuccessHandler((request, response, authentication) -> {
                    if (위에서 로그아웃이 되었으면) {
                        종료
                    }
                   로그아웃 종료 메시지 출력
                })
            );

이러한 형태로 구현하니 정상적으로 로그아웃이 되는 걸 확인할 수 있었다. 그리고 한 번 로그아웃 된 것은 예외로 401과 메시지를 날리게 하였다.

2. AWS와의 사투기록

이제 auth 부분을 하고, 회원 전체 조회나 회원에 대한 수정 CRUD를 임시로 name 정도만 체크한 후 AWS를 시작했다.
그리고 나는 임시로 체크한 것으로 인해 크게 후회하게 된다.

1. EC2와 RDS 기초 설정

기본적인 AWS 셋팅은 EC2로 인스턴스를 생성하고, 인스턴스를 생성한 후에는 보안규칙을 설정해 준 뒤에 RDS를 추가로 생성하여 EC2와 연결하는 것에 성공하였다.

이러한 형태로 EC2 서버가 우분투로 열린 걸 확인 할 수 있었다.

그리고 mySQL을 사용할 수 있게 원격에서 연결한 모습인데, 나중에 알고 보니까 배포를 할 때 내가 써야 할 방법은 이 방법이 아니었다 ㅠㅠㅠ

2. 서버에 프로젝트 이동

그리고 처음에는 프로젝트 전체를 git clone을 이용해서 EC2 서버에 넣어서 빌드하는 방식을 사용했었다. 그러나 튜터님이 그건 비효율적이라고 했고, 실제로도 지양하는 방식인 것으로 인지하여 jar 파일만 업로드 하는 걸 시도했다.
그런데 일단 jar 파일 업로드에서 또 막혔다.

스크롤바가 이지경이 되도록 업로드가 안 된 것이다.

그리고 겨우 위와 같이 jar 파일이 업로드 된 걸 확인 할 수 있었다.
주위 파일명들을 보면 별의 별 이상한 cd니, :wq니 있는데 이건 모두 내가 실수로 생성해버린 것들이다.
정말 나 스스로도 웃기고 어이없고 한 편으론 스스로에게 애잔했다.

3. 실행이 안된다!!

이제 드디어 설렘을 안고 실행을 하려고 빌드를 딱 하는데, 눈물나게도 메인이 없다는 메시지가 뜬다.
나는 빌드에 대한 기초 상식이 없는 바보였고, 그걸 몰라서 생긴 트러블인데 결국 혼자 하다가 원맨쇼를 한 기록이다.

3-1. 빌드를 다시 인텔리제이에서 해보자

인텔리제이에서 빌드를 하려는데 버전이 안 맞는다고 떴다.
알고보니 내가 자바를 버전 8로 깔아쓰고 있었다.

이건 약간의 무지와 변명인데 이미 나는 대학을 다니며 자바 8 버전을 깔아서 아무 문제 없이 항상 구동을 했었고, 인텔리제이에서 17버전을 다운받아서 실행했을 때도 아무 문제가 없었다.

그러나 빌드를 인텔리제이에서 터미널로 시도할 경우 에러가 생겼다.

그래서 8을 다 지우고 17을 새로 깔고, 자바에 대한 환경변수를 작성하였다. 땅을 치고 후회하게 될 일이었다.

환경변수도 추가하면서 에로사항이 있었다.

아니 왜 이렇게 되는거지?????????
그러다가 어떻게 저떻게 해서 추가를 한 후, 청천벽력처럼 내 컴퓨터에서 버전이 안 맞는다는 새빨간 메시지와 함께 프로젝트 전체가 실행이 안 되는 문제를 맞닥뜨렸다.

결국 나는 이것저것 하다가 안 되어서 다른 보조컴퓨터를 켰다. 현재도 보조컴퓨터로 모든 일들을 작성하는 중이다. 앞으로는 프로젝트를 앞두고 중요한 자바 파일을 지우고 새로 환경을 바꾸는 행동은 절대 하지 않아야 한다는 교훈을 얻었다.

3-2. 빌드가 뭐에요? 먹는 건가요?

나는 새로운 컴퓨터에서도 비슷한 문제를 발견했다. 왜냐하면 새 컴퓨터에도 8버전이 깔려있었기 때문이다. 그래서 빌드를 어떻게 해야할 지 몰라서 튜터님께 도움을 요청했다.

빌드를 코끼리 모양을 조작하여 할 수 있다는 걸 그제야 알았다. 결론은 위에서 말한대로 내가 바보였던 거였다.

그리고 실행이!!! 드디어 성공했다. 그러나 또!!! 데이터 베이스에서 오류가 발생했다.

4. 데이터 베이스에서의 오류는 RDS를 적용하라

RDS를 적용하기 위해 고군분투를 했다. 과금 없이 하는 방법은 EC2를 사용하여 SSH 터널링을 하는 방법이었다.
이 방법도 내가 어색하고 잘 모르는 방법이었기에 오래 걸렸지만 어떻게든 아래와 같이 MySQL로 성공하였다.

그런데... 또 안 된다고? jar 파일을 실행하는데 자꾸만 권한 때문에 문제가 발생했다. 이 부분은 인바운드 규칙과 아웃바운드 규칙 설정이 미비해서 그런 거여서, 그 부분을 해결하고 나니 무사히 배포에 성공했다.

배 포 성 공 오예!!!!!!!!!!!!!!

3. 스프링 시큐리티에서는 수정이 어렵다고??

그렇게 배포를 성공하고, 다시 로컬 환경으로 돌아와 일반 mySQL을 사용하여 임시로 name만 수정했던 정보수정을 시작했는데 비밀번호를 체크하고 수정하는 걸 반영 시키려고 보니 데이터 베이스 상에 문제가 발생했다.

바로 수정이 안 된다는 점이었다.

명시적으로 포스트맨에서는 수정이 되던 게 데이터 베이스에서는 수정이 안 된 것이다.

1. 원인 첫번째, 토큰을 써서

기존에 했던 방식을 참고해서 하다보니 일반 jwt 토큰을 가져와서 쓰려고 했던 게 큰 이유 중 하나였다.
이 부분은 CustomUserDetails 를 가져오는 것으로 해결이 되었다.

2. 원인 두번째, SecurityContextHolder를 놓침

그런데 또 제대로 안 되고 에러가 발생했다. 그래서 스프링 시큐리티에서 어떻게 내가 생성을 했는지 생성부분을 다시 뜯어봤다. 알고는 있었지만 놓친 부분은 SecurityContextHolder에도 새로운 값으로 업데이트를 해야한다는 점이었다.

 CustomUserDetails updatedUserDetails = (CustomUserDetails) userDetailsService.loadUserByUsername(updateUser.getLoginId());
        Authentication authentication = SecurityContextHolder.getContext().getAuthentication();

        SecurityContext context = SecurityContextHolder.getContext();
        context.setAuthentication(updateAuthentication(authentication, updatedUserDetails));
        SecurityContextHolder.setContext(context);

이런 식으로 contextHolder에 set을 해주니 이 부분도 해결이 된 것으로 보였다.

3. 원인 세번째, 유니크가 너무해

난 현재 식별자 id를 Long으로 쓰고 있고 로그인 시에 확인할 별도의 로그인 id를 추가로 String 값으로 유니크하게 설정해 둔 상태였다. 그런데 우리는 빌더 패턴을 사용하지 않는가? 그래서 처음에는 빌더 패턴으로 값을 업데이트 하고, save를 사용하여 실행을 했는데 유니크 값에 대한 컨플릭트가 났다.

빌더를 쓰되, 빌더에 기존 식별 id 값을 같이 저장하고 saveAndflush를 사용하면 영속성에서 오는 유니크 문제가 해결된다고 GPT가 알려주어서 그 부분을 해보았으나 여전히 안 되었다.

그래서 결론은 빌더를 포기하고 각각 Entity에 직접 업데이트 정보를 저장해주고, save를 하니 제대로 업데이트가 되었다.

4. 네? 쿠폰 발급이 불가하다고요?

이번에는 쿠폰을 담당한 팀장님께서 나에게 도움을 요청하셨다. 으악 살려줘요 선생님들, 벌써 밤 10시라고요

그리고 이상하게 쿠폰 부분만 자꾸 누락이 되고, 다른 부분은 잘 되는 현상을 발견했다.

이유는 바로 쿠폰에서는 ADMIN에 대한 설정을 해 둔 상태였기 때문이다.
스프링 시큐리티에서 기본적으로 USER_ROLE을 사용해야한다는 사실을 놓친 문제였다.

그래서 USER_ROLE을 추가해주고, 기본적으로 회원가입을 할 때 자동으로 USER라는 String 형태의 role을 저장하게 했다.

이런 방식으로 서비스 단에서도 추가해주고, 아래와 같이 jwt 필터에서도 role 정보를 가져와서 스프링 시큐리티에 반영되게 하였다.

결과물을 보면 이런식으로 반영이 되는 걸 확인했다.

근데 지금 발견했는데 시작과 끝날짜가 왜 null이지?
등골이 오싹한데..?

쎄함이 감지되었으나 오늘은 발표 당일, 어쩔 수 없다!!!

5. Swagger가 안되어 슬픈 자들

그리고 시간이 정말 오래 걸렸던 문제인데 우리는 스프링 시큐리티를 적용한 상태에서 스웨거 사용이 불가했다.

처음에는 아예 이런식으로 접근 자체가 불가했다.

그리고 현재도 이런 식으로 접근만 가능하고 v3~~하는 주소로 들어가면 위처럼 403 에러가 발생한다. 이 문제로 새벽 4시까지 고군분투 하였으나, 결국 미천한 내 능력의 한계로 스웨거를 포기하고 포스트맨으로 발표를 하게 될 것으로 보인다.