[Main Project] 메인 프로젝트 회고

✔️Date : 2022.11.08 ~ 2022.12.07

---

What did you do?

👩🏻‍🌾 자체 로그인과 소셜 로그인 구현

• JWT 토큰을 이용한 자체 로그인과 소셜 로그인 구현
• REST API를 이용하여 구현
• 프로젝트 이후 디밸롭 : 필터를 이용하여 자체 로그인과 소셜 로그인 구현, 소셜 로그인 리다이렉트 시 header로 토큰 전달

: 저번 프리 프로젝트 때에 소셜 로그인과 자체 로그인을 동시에 구현해내지 못했다. 때문에 이번에는 무조건 해내고 싶다는 생각이 들었다. 그래서 로그인 파트를 다시 만들게 되었을 때, 욕심을 좀 내보려고 했다. 처음에 필터로 사용해보려고 했으나, 소셜 로그인의 역할 구분에서 리다이렉트 시킬 수 있는 방법이 어려웠다. 그래서 반의 반 정도 구현했을 때에 일정 내에 해내지 못할 것 같아 REST API로 구현하는 것으로 수정하였다. REST API로 구현하면 내가 조금 더 커스텀 하기 쉽지 않을까 하는 생각 때문이었다. 실제로도 조금 더 커스텀 하기 쉬웠던 것 같다. 서비스 계층에서 토큰을 직접 발급 받고 컨트롤러에서 헤더에 넘길 수 있도록 설계하였다. 또한 소셜 로그인을 하였을 때, 프런트로 리다이렉트가 필요하였다. 이 때에도 직접 URI를 빌드하여 리다이렉트를 시켜주었다. 하지만 이 부분에서도 조금 아쉬운 점이 있었다. 바로 파라미터로 토큰을 전달하는 부분이다. HttpHeaders()를 이용하여 헤더에 추가하고 리다이렉트를 해보았는데, 헤더로 잘 안날아 가는 것으로 확인이 되었다. 그래서 파라미터로 던지게 되었다. 마지막에 시간이 모자란 상황이었어서 더 알아보지 못하고 이렇게 처리할 수 밖에 없었던 것이 너무 아쉬웠다. 그래도 개인적으로 뿌듯한 것은, 최초 소셜 로그인 시 역할을 선택할 수 있도록 설계한 부분이다. 서비스 특성상 소비자와 생산자가 나뉘었다. 근데 소셜로 들어오면 어떻게 선택해야할 지 어려웠다 이것을 리다이렉트 과정에서 프런트 분께서 해당 선택 페이지에서 역할을 선택하게 하여 해당 요청이 서버로 들어오면 해당 역할에 맞추어 토큰을 다시 재발급하여 다시 프런트에 전달해주었다. 그리고 이 페이지는 최초 소셜 로그인에만 적용할 수 있게 하였다. 이 부분은 사실 될 지 몰랐는데 구현할 수 있게 되어 굉장히 뿌듯했다! 

---

👩🏻‍🌾 토큰을 이용하여 유저 권한 판별

• 헤더에 들어오는 토큰에서 해당하는 권한을 가진 유저가 맞는지 확인
• Security FilterChain의 메서드를 이용하여 구현
• 프로젝트 이후 디밸롭 : 명시적으로 하나씩 적은 부분을 합쳐서 적기

: FilterChain의 authorizeHttpRequests()를 이용하여 uri와 method를 비교하여 권한을 제대로 가지고 있는지 판별하였다. 모두가 접근해야하는 부분과 권한별로 접근해야하는 부분을 나누었다. 명시적으로 하나씩 적어주었는데, 하나씩 확인하기 위해서 적었다. 이후 프로젝트가 끝나고는 해당 부분을 모아서 처리해 볼 생각이다. 왜냐하면, 위에 있는 순서별로 걸러지기 때문에 여러가지 묶을 때 그것을 고려해서 묶어봐야 하기 때문이다. 하나씩 있을 때에는 그 부분이 조금은 수월했기 때문이다. 

아래는 원래 준비했던 피피티의 일부이다. 만약 유저 권한이 필요한 경우 아래처럼 흘러간다. 

---

👩🏻‍🌾 회원 CRUD 구현

• 회원 관리 로직 CRUD 구현
• 회원 가입 시 환영 메일 발송
• 프로젝트 이후 디밸롭 : 이메일 인증 구현 혹은 비밀번호 찾기 구현 

: 로그인에 연결되어 회원 테이블을 맡아서 구현하였다. 회원 가입 및 수정, 조회, 삭제의 기본 CRUD를 구현하였는데, 전과 다른 점이 있다면 회원 테이블이 세 개로 나뉜다는 점이었다. 공통의 회원 테이블이 있고, 생산자와 소비자의 테이블을 나누어 구현하였다. 사실 이번 로직에서는 많이 다른게 존재하지 않았지만, 기능이 많아질 수록 나누어 구성하는 게 좋다고 전에 멘토님께서 조언을 해주신 적이 있다. 그래서 이번 경험이 좋았다. 그래서 엔티티도 나뉘고 서비스나 컨트롤러도 길어지지 않게 나누어서 구현하였다. 

---

👩🏻‍🌾 연관 관계

• 테이블 간의 연관 관계 연결
• 양방향 연결을 위한 연관 관계 편의 메서드 구현
• 프로젝트 이후 디벨롭 : 더 효율적인 연관 관계를 생각해 볼 것

: 위에 연결해서 엔티티 간의 연결관계를 설정해주었다. 연관 관계를 제대로 하지 않으면 삭제할 때에 문제가 생긴다. 이번에 프로젝트를 하면서 리뷰나 문의가 제대로 삭제가 안되면 탈퇴가 안되는 에러를 만났었다. 이유는 바로 한 쪽에만 연관관계를 주거나, 잘못된 방식으로 연관 관계에 있었던 부분들이 나중에 문제점으로 발견되는 것이었다. 사실 그동안 연관관계는 그냥 서로 참조해서 가져오는 거 정도로만 판단했었는데, 이번에 제대로 안하면 어떤 문제가 나타나는지 너무 뼈져리게 느꼈다. ER 다이어그램도 약 5~6번 정도 고친 것 같다. 처음에 정말 철저하게 한다고 했는데, 하다보니 바뀔 필요가 있는 부분들이 계속 나타났다. 

프로젝트가 끝났어도 이거보다 더 효율적인 연관관계가 있는지 생각해 보고 싶다. 왜냐하면, 그 이유는 아래에 리뷰에 설명하려고 한다. 

---

👩🏻‍🌾 구매를 한 회원만 리뷰 작성

• 쿼리를 이용하여 연관 관계에 있는 Client로 1차 주문 리스트를 가져옴
• Stream을 이용하여 filter로 주문 리스트의 상품 아이디와 리뷰를 쓰려는 곳의 상품 아이디가 일치하는 지 판별
• 다음으로 걸러진 주문 리스트에서 결제 완료가 존재하는지 판별
• 프로젝트 이후 디밸롭 : 일대일 연관관계로도 한 번 해보기

: 우리 서비스는 리뷰가 해당 글 게시판 아래에서 작성한다. 위에 ER 다이어그램처럼 연관 관계에서 리스트로 이용할 수 밖에 없었다. 만약 주문 내역에서 작성했다면 일대일로 가능했을 것이다. 그래서 이 부분도 한 번 구현해보려고 한다. 확실히 일대일로 한다면 해당 주문을 제대로 가지고 올 수 있을 것 같다. 만약 코드가 궁금하다면 아래의 글을 살펴보는 것을 추천한다.

[Main Project] Day 21 : 마지막 디밸롭 및 수정

---

👩🏻‍🌾 리뷰 삭제 시 게시판의 평점과 리뷰 개수 변화 구현 (+ 트랜잭션 문제)

• 리뷰를 삭제하면 평점과 리뷰 개수가 변해야 한다.
• 만약 리뷰가 1개이면, 레포지토리 클래스의 쿼리문으로 가져오지 못하니 임의로 지정해준다.
• 그리고 리뷰 개수와 평점을 다시 정리해준다.
• ⭐️ 트랜잭셔널 어노테이션이 없어야 한다. 있으면 롤백이 되어 지워지지 않는 오류가 발생한다. ⭐️
• 프로젝트 이후 디밸롭 :  트랜잭션 공부 및 정리

: 트랜잭션은 이번 프로젝트의 꽃이었다. 어떤 서비스는 트랜잭션 어노테이션을 붙이지 않아서 오류가 발생하고, 어떤 서비스는 붙여서 오류가 발생했다. 이렇게 변화를 줘야하는 메서드에 @Transactional 어노테이션을 잘못 붙이면 변화가 생기지 않았고, 메서드 안에 로직들이 하나로 가야 하는 부분에 @Transactional 어노테이션을 붙이지 않으면 하나는 일어나고 하나는 일어나지 않는 에러가 발생했다.

첫 번째의 경우의 에러는 이 평점과 리뷰 변화와 OrdService에서 주문시 주문 상태가 주문 완료에서 결제 완료로 바뀌는 부분에서 경험하였다. 평점과 리뷰 변화에서는 리뷰가 삭제되지 않고 계속 DB에 남는 오류가 발생했고, 주문 서비스에서 상태를 변화할 때에는 상태가 계속 변하지 않는 오류를 겪었다. 반대로 두 번째의 경우의 예시는 Board와 Product였다. 우리 로직에서는 두 테이블이 일대일로 연관이 되어있고, 게시판을 등록할 때에 상품이 등록되기 때문에 아이디가 똑같아야 했다. 하지만 어느 순간 게시판과 상품의 아이디가 다르게 가는 것이었다. 이유는 바로 이 @Transactional이 없어서였다. 해당 부분이 없어서 트랜잭션의 원자성과 격리성이 보장되지 못하였다. 때문에 여러명이 등록하면 두 아이디가 꼬인 경험, Board에서 에러가 발생해 등록되지 않았음에도 Product만 등록되는 경험을 하였다. 

그래서 트랜잭션에 대해서 조금 더 많은 공부가 필요하다는 것을 느꼈다.

해당 에러의 경험은 아래 블로그에 짧게 써있다.

[Main Project] Day 20 : 소셜로그인 권한 수정

---

👩🏻‍🌾 토큰 재발급 구현

• 엑세스 토큰 혹은 리프레시 토큰 만료 시 재발급 할 수 있도록 구현
• AOP, REST API로 구현
• 프로젝트 이후 디밸롭 : 다른 효율적인 방법을 생각해 볼 것

: JWT 토큰을 이용해 로그인을 구현하다보니 자연스럽게 토큰의 만료시간을 생각하게 되었다. 그래서 이 만료를 어떻게 구현할 지 생각해보았다. 방법은 두 가지로 구현해보았다. 첫 번째 방법은 내가 클라이언트에게 만료가 되었음을 알리면 클라이언트가 재발급 엔드포인트로 재발급 요청을 보내는 것이다. 두 번째는 AOP로 토큰이 들어올 때마다 검사해서 만료 시간이 임박했으면 자동으로 재발급 해서 다시 헤더에 담아 되돌려 주는 것이다. 첫 번째 방법은 위의 방법이다. 엑세스 토큰을 재 발급 하고, 만약 리프레시 토큰의 시간이 하루 이하로 남았다면 재발급 해서 리프레시 토큰을 업데이트해서 저장소에 저장한다.

@Transactional
public TokenDto reissueRefresh(HttpServletRequest request, HttpServletResponse response) {

   /* Access Token 확인 */
   String accessToken = request.getHeader("Authorization").replace("Bearer ","");

   if (!securityProvider.validate(accessToken)) {
      log.error("유효하지 않은 access token");
      throw new BusinessLogicException(ExceptionCode.UNAUTHORIZED_TOKEN);
   }

   Map<String, Object> claims = securityProvider.parseClaims(accessToken);

   if (claims == null) {
      throw new BusinessLogicException(ExceptionCode.NOT_EXPIRATION_TOKEN);
   }

   /* Refresh Token 확인 */
   String username = (String)claims.get("username");
   String refreshToken = CookieUtil.getCookie(request, "Refresh")
      .map(Cookie::getValue)
      .orElseThrow(() -> new BusinessLogicException(ExceptionCode.LOGOUT_MEMBER));

   RefreshToken userRefreshToken =
      refreshTokenRepository.findByKey(username)
         .orElseThrow(() -> new BusinessLogicException(ExceptionCode.LOGOUT_MEMBER));

   if (securityProvider.validate(refreshToken)) {
      log.error("유효하지 않은 refresh token");
      throw new BusinessLogicException(ExceptionCode.UNAUTHORIZED_TOKEN);
   }

   long now = (new Date()).getTime();
   long validTime = securityProvider.getTokenClaims(refreshToken).getExpiration().getTime() - now;

   /* 리프레시 토큰이 하루 이내로 남았다면, 재 발급 (엑세스 토큰도 같이 재발급) */
   if (validTime <= 1000 * 60 * 60 * 24) {

      TokenDto tokenDto = securityProvider.generatedTokenDto(username);

      accessToken = tokenDto.getAccessToken();
      refreshToken = tokenDto.getRefreshToken();

      /* Refresh DB update */
      userRefreshToken.updateValue(refreshToken);
      refreshTokenRepository.saveAndFlush(userRefreshToken);

      int cookieMaxAge = (int) 1000 * 60 * 24 * 7;
      CookieUtil.deleteCookie(request, response, "Refresh");
      CookieUtil.addCookie(response, "Refresh", refreshToken, cookieMaxAge);
   }

   /* 리프레시 토큰이 유효한데 보낸 설정이기에 예외 던지기 */
   log.error("refresh token 이 만료되지 않았습니다.");
   throw new BusinessLogicException(ExceptionCode.NOT_EXPIRATION_TOKEN);
}

두 번째 방법은 아래의 방법이다. 먼저 어노테이션을 하나 만들고, Aspect 어노테이션으로 AOP를 처리를 해준다. 그리고 토큰이 들어오면 해당 토큰의 유효시간을 확인해서 유효시간이 임박하면 재발급을 해서 헤더에 넘겨준다. 리프레시 토큰도 유효시간이 임박하면 업데이트해서 저장소에 저장한다.

@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.METHOD)
public @interface ReissueToken {
}

 

@Aspect
@Component
@Slf4j
@RequiredArgsConstructor
public class SecurityAspect {

   private final SecurityProvider securityProvider;
   private final RefreshTokenRepository refreshTokenRepository;

   @Before("@annotation(reissueToken)")
   public void getAccessTokenAgain(ReissueToken reissueToken) throws Throwable {
      log.info("# 어노테이션 토큰 유효성 검사 시작");
      ServletRequestAttributes requestAttributes = (ServletRequestAttributes) RequestContextHolder.currentRequestAttributes();
      HttpServletRequest request = requestAttributes.getRequest();
      HttpServletResponse response = requestAttributes.getResponse();

      String accessToken = request.getHeader("Authorization").replace("Bearer ", "");
      Authentication authentication = securityProvider.getAuthentication(accessToken);
      RefreshToken refreshTokenTable = refreshTokenRepository.findByKey(authentication.getName())
         .orElseThrow(()-> new BusinessLogicException(ExceptionCode.NOT_FOUND_TOKEN));
      String refreshToken = refreshTokenTable.getValue();

      if (accessToken == null) {
         log.error("엑세스 토큰을 찾을 수 없습니다.");
         throw new BusinessLogicException(ExceptionCode.NOT_FOUND_TOKEN);
      }

      /* 토큰 유효 시간 */
      Date now = new Date();
      long accessValidTime = securityProvider.getTokenClaims(accessToken).getExpiration().getTime() - now.getTime();
      long refreshValidTime = securityProvider.getTokenClaims(refreshToken).getExpiration().getTime() - now.getTime();

      /* 엑세스 토큰의 시간이 10분 이내로 남았다면 재 발급 */
      if (accessValidTime <= 1000 * 60 * 10) {
         log.info("# 엑세스 토큰 재 발급");
         String role = authentication.getAuthorities().toString().replace("[ROLE_","").replace("]", "");

         Date newAccessExpiration = new Date(now.getTime() + securityProvider.getAccessTokenTime());
         accessToken =
            securityProvider.createAccessToken(authentication.getName(), role, newAccessExpiration);
      }

      /* 리프레시 토큰의 시간이 하루 이내로 남았다면 재 발급 */
      if (refreshValidTime <= 1000 * 60 * 60 * 24) {
         log.info("# 리프레시 토큰 재 발급");
         Date newRefreshExpiration = new Date(now.getTime() + securityProvider.getRefreshTokenTime());
         refreshToken = securityProvider.createRefreshToken(authentication.getName(), newRefreshExpiration);

         refreshTokenTable.updateValue(refreshToken);
         refreshTokenRepository.saveAndFlush(refreshTokenTable);
      }

      response.setHeader("Authorization", accessToken);

      log.info("# 어노테이션 토큰 유효성 검사 종료 ");
   }
}

프로젝트가 끝나고 좀 더 깔끔하게 코드를 정리해서 적을 수 있도록 해봐야겠다.

---

👩🏻‍🌾 현재 로그인한 유저 판별

• 현재 로그인한 유저와 접근하려는 페이지의 유저가 같은지 판별이 필요
• 공통의 클래스를 만들고, 멤버 서비스 단에 해당 클래스를 이용하여 판별 메서드 작성

: 저번 프리 프로젝트 때에는 Principal 객체로 일일이 컨트롤러에서 작업을 해주었다. 개인적으로 그게 굉장히 효율적이지 못하다는 것을 느꼈다. 왜냐하면, 결국 비슷한 로직의 반복이기 때문이다. 그래서 이것을 어떻게 하면 효율적으로 불러오고 판별할 수 있을까 생각해보았다. 이렇게 판별하는 이유는 해당 페이지 요청 권한은 정말 권한만 보기 때문이다. 그렇기 때문에 이 페이지의 주인인 유저가 아니어도 접근이 가능할 수 있기 때문에 백에서도 막아야 하는 것이다. 

아래처럼 SecurityUtil이라는 클래스를 만들어줬고 ContextHoder에서 정보를 가져와 현재 로그인 한 유저의 이메일을 가져올 수 있도록 구현하였다. 우리 로직에서 이메일은 아이디로, 유니크한 값을 지녔기 때문이다. 생산자의 경우 생산자 마이페이지를 모두가 접근할 수 있고, 소비자는 자신만 접근 할 수 있다. 그래서 소비자는 소비자 서비스에 만들고 소비자를 찾는 메서드에 해당 메서드를 실행시켜 소비자를 찾을 경우 자동으로 찾을 수 있도록 설계하였다. 따라서 생산자도 생산자 서비스에 만들고 필요에 따라 불러올 수 있도록 하였다.

개인적으로 이렇게 하니 훨씬 효율적이었던 것 같다고 생각한다.

public class SecurityUtil {
   private SecurityUtil() {}

   public static String getCurrentEmail() {

      /* ContextHolder 에서 정보 가져오기 */
      final Authentication authentication = SecurityContextHolder.getContext().getAuthentication();

      if (authentication == null || authentication.getName() == null) {
         throw new RuntimeException("해당하는 인증 정보가 존재하지 않습니다.");
      }

      return authentication.getName();
   }
}

 

/* 소비자 조회 */
@Transactional(readOnly = true)
public Client findClient(long clientId) {
	correctClient(clientId);
	Client client = findVerifiedClient(clientId);

	return client;
}

/* 로그인 한 사용자와 접근 사용자 판별 */
public void correctClient(long accessId) {
   String email = SecurityUtil.getCurrentEmail();
   Member loginMember = memberService.findMemberByEmail(email);
   log.info("로그인한 유저 : {}", loginMember.getName());

   if (loginMember.getClient().getClientId() != accessId) {
      throw new BusinessLogicException(ExceptionCode.WRONG_ACCESS);
   }
}

 

/* 로그인 한 사용자와 접근 사용자 판별 */
public void correctSeller(long accessId) {
    String email = SecurityUtil.getCurrentEmail();
    Member loginMember = memberService.findMemberByEmail(email);
    log.info("로그인한 유저 : {}", loginMember.getName());

    if (loginMember.getSeller().getSellerId() != accessId) {
        throw new BusinessLogicException(ExceptionCode.WRONG_ACCESS);
    }
}

---

👩🏻‍🌾 카카오 페이 구현

• 카카오 페이 API를 이용한 결제 구현
• 프로젝트 이후 디밸롭 : 다른 PG사 확인해보기

: 이번 프로젝트에서 가장 해보고 싶었던 도전인 부분이었다. 그래서 세 팀원 모두 해보고 가장 먼저 되는 팀원의 코드를 커밋하기로 했다. 그래서 나도 같이 구현을 해보았다. 카카오 페이 API는 카카오 문서로 굉장히 잘 정리되어 있었고, 해당 문서 덕분에 조금 더 수월하게 할 수 있었다. 그리고 하면서 처음 구현해 본 파트지만 굉장히 신기하고 재밌었다. 또한 기능을 구현함에 있어서 정리가 필요하다고 판단이 되어  이 파트는 여기다 정리하는 것이 아닌 따로 포스팅을 하는 게 좋을 것 같다고 생각이 들었다.

 

+ 포스팅 완료

[Spring] Spring boot Java 카카오 페이 단건 결제 구현하기

---

돌아보기

: 이번 메인 프로젝트 때에는 프리 때 보다 더 발전하고 싶었다. 그래서 팀원 분들과 욕심도 내보고 문제가 생기면 같이 해결하기도 하였다. 그래서 전체적인 코드의 흐름도 그래도 이해할 수 있었고, 덕분에 문제가 발생하면 같이 해결할 수도 있었다. 그리고 굳이 욕심내지 않아도 되지만 해보고 싶은 부분들을 계속해서 추가해나갔다. 때문에 많이 성장하지 않았을까 조금은 기대가 된다.

당장 엄청난 실력자는 아니지만, 그래도 4개월의 과정에서 빠르게 지나갔던 부분들에 대해서 전보다는 이해가 많이 되고, 흐름도 보이고, 내가 어느 정도는 설명할 수 있지 않나 하는 생각이 들었다. 그리고 개인적으로 나에게 아쉬웠던 부분들이 있었는데, 생각보다 내가 일정 관리를 너무 러프하게 한 부분이 있었다. 그게 나중에는 몰아쳐서 조금 어려웠던 것 같다. 조금씩 나누어 분배하는 스킬을 키워야겠다. 그리고 Stream이나 여러 다른 방식을 찾아볼 때, 얼마나 기초가 중요한지 그리고 알고리즘이 중요한지를 깨달았다. 그래서 해당 스터디를 하나 만들어서 공부하려고 한다!