collabu / pennyway-was Goto Github PK

추가할 기능

할 일 목록

• 배포 방식 정하기
• CI/CD 파이프라인 수정
• EC2 인스턴스 8081 포트 허용

설명

현재 배포 작업 시 Docker 이미지를 교체하기 위한 텀이 있으나, 이를 제거하여 무중단 배포를 하고자 함

참고 자료

• https://llshl.tistory.com/47

추가할 기능

• Device Token 관리 정책을 준수하기 위한 Scheduler

할 일 목록

• 매월 활성 Device Token의 유효성 검사 후, 유효하지 않으면 비활성 토큰으로 변경
• 수정 타임 스탬프가 2개월이 지난 활성화 토큰을 비활성 토큰으로 변경

설명

FCM에서 권장하는 Token 관리 정책

• FCM 권장사항에 따르면 Server에 저장된 FCM Token은 주기적으로 비활성 여부를 관리해주어야 한다.

iOS에서 FCM 관리 정책

1. 사용자가 앱을 실행했을 때, 기기에 저장한 Device Token 존재 유무 확인
   1-1. 없으면 FCM 토큰 발급 요청 후
   1-2. 서버에 저장 요청 후 사용자 기기에 "토큰"과 "발급받은 날짜" 저장
   1-3. 시나리오 종료
2. Device Token 발급 날짜 확인
   2-1. 한 달 이상 지났으면 FCM 재발급 요청
   2-2. 기존 토큰과 재발급 받은 토큰을 서버로 전달
   2-3. 시나리오 종료
3. Device Token이 존재하고, 한 달 이상 지나지 않았으면 그대로 시나리오 종료.

BE에서 FCM 관리 정책

• 매월 FCM 토큰의 API로 전송해 유효성을 검증하고, 유효하지 않은 토큰을 비활성 토큰으로 변경한다.
• 가끔 유효하지 않은데 유효한 응답을 반환하는 경우가 있으므로, 수정되고 2달 이상 지난 토큰은 자동으로 비활성화 처리한다.

버그 내용

• RTR 기법이 적용되지 않아, AT는 재발급되는데 RT는 변경된 토큰이 redis에 반영되지 않음.

버그 위치

• kr.co.pennyway.domain.common.redis.refresh
• RefreshTokenServiceImpl 클래스의 refresh() 메서드

• 현재 save()를 했을 때, 정상적으로 변경값이 저장되지 않고 있다고 추측

재현

• refresh()를 호출해도 redis 내 token 정보가 변경되지 않음.

할일

• 재발급된 refresh token이 redis에 반영되도록 수정

추가할 기능

• 커스텀 어노테이션으로 모든 request, response에 대한 log를 남기는 AOP 기능 개발

할 일 목록

• 커스텀 어노테이션 작성
• request, response 정보를 출력하는 AOP 기능 개발
• 테스트 케이스 작성

설명

• 서버에서 관리해야 할 로그들
• Log에 대한 Convention이 없는 상태로 개발을 지속할 시, 문제가 발생했을 때 원인을 파악하기 매우 힘들다는 문제 인지
• 최소한 request, response에 대한 log를 관리를 필수적으로 해야하며, 중복 코드를 방지하기 위해 AOP 기능 활용
  • 단, 모든 요청과 응답에 대해 보안이 중요한 항목들은 암호화되어 있다고 가정한다.
  • 따라서 로그 레벨은 모두 info로 설정

버그 내용

• [4-1] 계정 연동에서 Entity가 매핑되지 않아 OAuth 정보가 테이블에 반영되지 않음.

버그 위치

@Mapper
@RequiredArgsConstructor
public class UserOauthSignMapper {
    ...

    /**
     * 기존 계정이 존재하면 Oauth 계정을 생성하여 연동하고, 존재하지 않으면 새로운 계정을 생성한다.
     *
     * @param request {@link SignUpReq.OauthInfo}
     */
    @Transactional
    public User saveUser(SignUpReq.OauthInfo request, Pair<Boolean, String> isSignUpUser, Provider provider, String oauthId) {
        User user;

        if (isSignUpUser.getLeft().equals(Boolean.TRUE)) {
            user = userService.readUserByUsername(isSignUpUser.getRight())
                    .orElseThrow(() -> new UserErrorException(UserErrorCode.NOT_FOUND));
            Oauth.of(provider, oauthId, user);
        } else {
            user = User.builder()
                    .username(request.username())
                    .name(request.name())
                    .phone(request.phone())
                    .role(Role.USER)
                    .profileVisibility(ProfileVisibility.PUBLIC).build();
            userService.createUser(user);
            Oauth.of(provider, oauthId, user);
        }

        return user;
    }
}

• 아마도 영속화된 User entity에서 Oauth 정보를 매핑해주지 않으면서, OauthService.save()도 해주지 않기 때문이라고 추측

재현

• iOS 요청이 있어야 해서 재현은 불가하지만, 회의를 통해서 레코드가 갱신되지 않음을 확인.

할일

• User entity에 List<Oauth>를 관리하여 연관관계 도우미 메서드를 호출하도록 수정

As-is

현재 Pennyway WAS의 응답 체계는 다음과 같습니다.

{
   "code": "0000000", // 상태(3), 이유(1), 도메인(2), 필드(1)
   "message": ""
}

사용자(domainCode=1)가 회원가입을 위해 정보를 보냈는데, 아이디(fieldCode=2)가 누락(reasonCode=0)되어 에러(statusCode=422)를 응답해야 하는 상황일 때,
에러 코드는 4220012가 되어야 합니다.

그러나 만약 @Valid를 사용하여 Framework에 의존하면 다음과 같은 문제가 발생합니다.

public class SignUpRequest {
    @NotNull(message = "아이디는 필수값이어야 합니다.")
    private final String username;
    ...
}

여기서 username이 누락되면, valid check에 실패하므로 해당 작업을 처리하는 Validator로 흐름이 넘어가게 됩니다.
그리고 MethodArgumentNotValidException이 발생하여 @RestControllerAdvisor로 등록한 공통 예외 처리 핸들러에서 예외를 받도록 처리합니다.

문제

• 예외를 받은 시점에선 어떤 요청에서 에러가 발생했는지 알 수가 없다.
  • 똑같이 MethodArgumentNotValidException가 발생했지만 회원가입 과정에서 필드 누락에 의함인지, 게시물 등록에서 필드 누락이 된 건지 알 방도가 없다.
  • MethodArgumentNotValidException 내부에 커스텀 예외를 삽입하는 방법을 고민해보았지만, 해당 예외를 생성해내는 제어자의 로직에 관여할 방도가 없다.
• 위의 이유로 인해 DomainCode와 FieldCode를 유추할 방법이 없다.
  • Entity와 Dto의 필드를 완전히 동일하게 맞춘다면, 누락된 필드명을 찾아낼 수는 있다.
  • 하지만 만약 valid가 실패한 필드명이 aDomain, bDomain 모두 존재한다면 어느 Domain의 FieldError인지 알 수 없다.

현재 선택한 방법

1. Valid check를 위한 어노테이션 message에 domain 이름을 명시한다.
   • ex) user:아이디는 필수값이어야 합니다.
2. 전역 예외 처리 핸들러에서 :를 기준으로 문자열을 split 하여 Domain과 field를 추론해낸다.

문제점

• 로직이 문자열에 의존하며, 프로그래머의 작은 실수에도 프로그램이 오작동할 수 있다.
• MethodArgumentTypeMismatchException는 여전히 알아낼 수 있는 방법이 없다.

논의 사항

• 해당 방법을 다르게 처리할 방법이 있을지?
• 혹은 에러 코드 응답 체계를 수정해야 할 지?

버그 내용

• Client의 idToken 서명 검증 시 No matching key found 에러 발생

버그 위치

    /**
     * 공개키로 서명을 검증하는 메서드
     */
    private Jws<Claims> getOIDCTokenJws(String token, String modulus, String exponent) {
        try {
            return Jwts.parser()
                    .verifyWith(getRSAPublicKey(modulus, exponent))
                    .build()
                    .parseSignedClaims(token);
        } catch (JwtException e) {
            ...
        }
    }

• OauthOidcProviderImpl의 서명 검증 실패

재현

• Client가 발급받은 idToken이 필요하여 개별적으로 재현 불가

할일

• cache miss에 대한 대응책 마련
  a. cache ttl 기간을 줄인다.
  b. cache miss가 발생하면 다시 Public Key를 조회한다. ⇾ 가장 타당함. 서명 검증 전에 Payload를 검증하므로, 악의적인 공격을 차단한 상태에서 cache miss가 발생했다면 재조회를 하는 것이 맞을 것 같음.

논의 주제

• AWS access key, refresh key 주입 방식에 대해서

논의 내용

• 현재 AWS Config 권한 설정 방식은 환경 변수를 주입하여 인증함.

@Getter
@Configuration
public class AwsSnsConfig {
    private final String accessKey;
    private final String secretKey;
    private final String region;

    public AwsSnsConfig(
            @Value("${spring.cloud.aws.sns.credentials.access-key}") String accessKey,
            @Value("${spring.cloud.aws.sns.credentials.secret-key}") String secretKey,
            @Value("${spring.cloud.aws.sns.region.static}") String region
    ) {
        this.accessKey = accessKey;
        this.secretKey = secretKey;
        this.region = region;
    }

    @Bean
    public AwsCredentials awsSnsCredentials() {
        return AwsBasicCredentials.create(accessKey, secretKey);
    }

    ...
}

• 하지만 AWS 권고 사항에 따르면 EC2 서버에서는 다음과 같이 인증을 해야 합니다.

@Configuration
public class AwsConfiguration {
    @Value("${cloud.aws.credentials.access-key}")
    private String awsAccessKey;

    @Value("${cloud.aws.credentials.secret-key}")
    private String awsSecretKey;

    @Value("${cloud.aws.region.static}")
    private String region;

    @Value("${spring.profiles.active:}")
    private String activeProfile;

    @Bean
    public AmazonSNSClient amazonSNSClient(Environment environment ) {
        if(StringUtils.equals(activeProfile , "")){
            return (AmazonSNSClient) AmazonSNSClientBuilder
                    .standard()
                    .withRegion(region)
                    .withCredentials(InstanceProfileCredentialsProvider.getInstance())
                    .build();
        }else{
            return (AmazonSNSClient) AmazonSNSClientBuilder
                    .standard()
                    .withRegion(region)
                    .withCredentials(new AWSStaticCredentialsProvider(
                            new BasicAWSCredentials(environment.getProperty("cloud.aws.credentials.access-key"), environment.getProperty("cloud.aws.credentials.secret-key"))))
                    .build();
        }
    }
}

따라서 추후 위의 방식대로 변경해보고자 하는데, 어떻게 생각하시나요?

버그 내용

• #67 인증된 사용자 소셜 계정 연동에서 발견한 Soft Delete 정책이 반영되고 있는지 테스트 케이스로 검토

버그 위치

• 아직 에러가 발생하는 지 알 수 없음.

재현

• 없음

할일

• OauthController와 관련된 UseCase에 대한 통합 테스트 케이스 작성
• 필요 시, Soft Delete 정책을 반영하여 로직 개선 필요
• (LoC가 생각보다 많지 않으면 idToken의 oauth_id 검사 항목을 OauthOidcHelper로 넣어버릴 예정...ㅎ)

이슈 주제

• Device API에서 예외 시나리오에 대한 대응 방향 모색

이슈 설명

• FCM에서 권장하는 Device Token 관리 정책을 준수하기 위해서 추후 BE에서 스케줄링을 통한 관리를 진행할 예정.
• 현재 방식에서 2가지 문제점이 존재함.

1. Device Token을 갱신할 때 사용자 Device 정보도 함께 받음.
   • 사용자의 os가 변경될 수도 있기 때문에, device token 정보가 변경되지 않았음에도 updated_at 필드가 갱신되는 이슈
2. Client와 Server가 별도의 정책으로 토큰을 관리하고 있음.
   • Server는 Client가 새로운 토큰 등록과 토큰 갱신에 따라 올바른 요청을 보낼 것이라 기대함.
   • 하지만 사용자가 App 데이터를 삭제하는 경우, Client는 새로운 토큰 등록으로 보내는 문제가 발생함.
   • 토큰이 갱신되지 않았다면 Server가 핸들링하고 있지만, App 데이터가 제거된 후 FCM 토큰까지 재발급되는 경우 쓰레기 데이터가 지속적으로 쌓이게 됨.
   • 현재 정책으로는 쓰레기 데이터라고 판단하고 삭제할 수 있는 근거가 존재하지 않음.

할 일 목록

• Device 정보와 DeviceToken 테이블 분리 여부 논의
• 지속적으로 쌓이는 쓰레기 데이터의 처리 정책 논의