[Spring 장바구니 - 1단계] 연로그(권시연) 미션 제출합니다. #31

yeon-06 · 2022-06-01T16:25:57Z

안녕하세요 범블비! 연로그입니다😄

이번 미션에는 레거시 코드들이 존재하는데요
1단계는 요구 사항에 따라 회원 관련 API만 구현 하였으며 그 외 product, order 등의 레거시 코드들은 2단계 때 리팩터링할 예정입니다!
auth 폴더 및 shoppingcart 내부의 customer 위주로 리뷰를 주시면 감사합니다!

그리고 이번 미션에 대해 가장 많이 고민했던건 Password의 암호화 부분인데요
처음에는 Password 생성자에서 encrypt 처리를 해줬다가 DB에서 불러온 비밀번호를 가져올 때 곤란을 겪었습니다
DB에는 암호화된 비밀번호를 저장합니다.
이를 Password로 변환할 때 new Password(DB에서 가져온 비밀번호)를 거치는 바람에 암호화가 2번 되어버립니다.
따라서 여러가지 방안을 생각해보았는데요

암호화 된/되지 않은 텍스트 구분을 위한 정적 팩터리 메서드 생성
- Password.encrypt()와 Password.plain() 딱 봤을때 뭐가뭔지 혼동이 옴 (경험담)
Password는 인터페이스화 시키고 이를 구현한 EncodePassword, RawPassword 따로 생성
- 과한 설계처럼 느껴짐
암호화 작업을 Password 밖에서 수행
- 글자수 체크하는 등의 validate 작업도 Password 밖에서 수행해야함
암호화 관련 클래스를 의존 관계로 주입하고 encrypt() 메서드 따로 수행 필요 (현재 선택한 방법)

범블비라면 어떤 방법을 선택하실지, 이 외에도 방법이 있을지 궁금합니다!

- 비밀번호 조합 조건 수정 - 비밀번호 조합 테스트 케이스 추가

- 하드 코딩 제거 - 메서드 분리

- 불필요한 import문 삭제

- account로 조회하는 경우 Optional 반환 - TokenResponse 위치 변경 - 레거시 코드 username -> account 명칭 변경

- 잘못된 예외 문구 수정

- 하드 코딩 제거 - 메서드 이름 변경 - 메서드 분리 - given, when, then 분리 - 줄바꿈 추가/제거

- 메서드 이름 변경 - 클래스 이름 변경 - 줄바꿈 추가/제거

ddaaac

안녕하세요 👋

장바구니 1단계 미션 구현 잘 해주셨습니다!

몇 가지 코멘트를 남겼으니 확인 부탁드려요~ 질문은 편하게 DM 주세요!

ddaaac · 2022-06-02T14:25:26Z

src/main/java/woowacourse/auth/config/AuthenticationPrincipalConfig.java

+    @Override
+    public void addInterceptors(InterceptorRegistry registry) {
+        registry.addInterceptor(authenticationInterceptor())
+                .addPathPatterns("/customers/**");
+    }
+
+    @Bean
+    public AuthenticationInterceptor authenticationInterceptor() {
+        return new AuthenticationInterceptor(jwtTokenProvider);
+    }
+
    @Bean
    public AuthenticationPrincipalArgumentResolver createAuthenticationPrincipalArgumentResolver() {
-        return new AuthenticationPrincipalArgumentResolver(authService);
+        return new AuthenticationPrincipalArgumentResolver(jwtTokenProvider);
    }


Interceptor와 ArgumentResolver를 사용해서 적절하게 책임을 나누어주셨군요 👍
이 두 객체가 꼭 스프링이 관리하는 Bean이여야하는지 한 번 고민해보시면 좋을 것 같습니다.

큰 의미를 갖고 짠 코드가 아닌데 빈 등록의 의미가..... 없는 것 같아요😅
애초에 addInterceptors/addArgumentResolvers 를 서버가 구동될 때 단 한번만 호출할거라는 생각이 드네요
싱글톤으로 관리할 필요도 없고 의존 관계를 주입할 일도 없고 필요 없다고 판단했습니다!
리팩터링 때 제거하겠습니다 :D

맞습니다. 현재 스프링의 빈 등록 방식은 크게 2가지가 많이 사용되는데요, 하나는 @Component를 이용한 방식이고 다른 하나는 @Configuration과 @Bean을 활용한 방식입니다. 후자의 가장 큰 장점은 명시적으로 원하는 객체만을 빈으로 등록할 수 있다는 점이에요. 전자는 의존 관계를 갖는 모든 클래스들을 빈으로 등록해줘야 하죠.
이 글을 한 번 읽어보시면 도움이 될 것 같습니다 :)

ddaaac · 2022-06-02T14:26:19Z

src/main/java/woowacourse/auth/support/AuthorizationExtractor.java

-    public static String extract(HttpServletRequest request) {
-        Enumeration<String> headers = request.getHeaders(AUTHORIZATION);
-        while (headers.hasMoreElements()) {
-            String value = headers.nextElement();
-            if ((value.toLowerCase().startsWith(BEARER_TYPE.toLowerCase()))) {
-                String authHeaderValue = value.substring(BEARER_TYPE.length()).trim();
-                request.setAttribute(ACCESS_TOKEN_TYPE, value.substring(0, BEARER_TYPE.length()).trim());
-                int commaIndex = authHeaderValue.indexOf(',');
-                if (commaIndex > 0) {
-                    authHeaderValue = authHeaderValue.substring(0, commaIndex);
-                }
-                return authHeaderValue;
+    public static String extract(String value) {
+        if ((value.toLowerCase().startsWith(BEARER_TYPE.toLowerCase()))) {
+            String authHeaderValue = value.substring(BEARER_TYPE.length()).trim();
+            int commaIndex = authHeaderValue.indexOf(',');
+            if (commaIndex > 0) {
+                authHeaderValue = authHeaderValue.substring(0, commaIndex);


기존 코드를 적절하게 리팩토링해주셨군요 💯

다만, 이 메서드가 기존과 동일한 동작을 하는지 검증이 필요하다는 생각이 드네요 😄

완전히 동일한 동작을 하진 않았지만 코드를 개선하면서 필요에 맞게 개선되었습니다!

NativeWebRequest를 HttpServletRequest로 변환하는 것보다 NativeWebRequest에서 특정 값을 꺼내고 해당 값을 보내주는게 더 편하다고 생각했어요
검색하다보니 아래 코드를 통해서 편하게 변환되기는 하네요🤔

webRequest.getNativeRequest(HttpServletRequest.class);

조금 더 생각하다보니 Authorization이 아닌 다른 위치에서 값을 꺼내서 보낼 수도 있다는 생각이 들어요
HttpServletRequest를 보내는 방향으로 리팩터링 했습니다!

리팩토링 잘 해주셨어요 💯
다만, 코멘트의 의도는 테스트 코드를 작성하면 좋을 것 같다는 의도였어요.
기존 코드를 리팩토링할 때, 테스트 코드 작성 -> 리팩토링의 순서대로 하면 안정적으로 리팩토링이 가능합니다!

ddaaac · 2022-06-02T14:28:29Z

src/main/java/woowacourse/auth/support/JwtTokenProvider.java

+        return Jwts.parserBuilder()
+                .setSigningKey(Keys.hmacShaKeyFor(secretKey.getBytes(StandardCharsets.UTF_8)))
+                .build()
+                .parseClaimsJws(token)
+                .getBody()
+                .getSubject();
    }

-    public boolean validateToken(String token) {
+    public void validateToken(String token) {
        try {
-            Jws<Claims> claims = Jwts.parser().setSigningKey(secretKey).parseClaimsJws(token);
-
-            return !claims.getBody().getExpiration().before(new Date());
-        } catch (JwtException | IllegalArgumentException e) {
-            return false;
+            Jwts.parserBuilder()
+                    .setSigningKey(Keys.hmacShaKeyFor(secretKey.getBytes(StandardCharsets.UTF_8)))
+                    .build().parseClaimsJws(token);


중복되는 로직들은 메서드 분리를 할 수 있지 않을까요?

ddaaac · 2022-06-02T14:30:15Z

src/test/java/woowacourse/auth/support/JwtTokenProviderTest.java

+@DisplayNameGeneration(DisplayNameGenerator.ReplaceUnderscores.class)
+@SuppressWarnings("NonAsciiCharacters")
+@DisplayName("JWT 기능 관련")
+class JwtTokenProviderTest {


기존 코드에 대한 테스트 구현 💯

ddaaac · 2022-06-02T14:41:20Z

src/main/java/woowacourse/shoppingcart/domain/customer/vo/Password.java

+    public void encrypt(PasswordEncoder passwordEncoder) {
+        value = passwordEncoder.encrypt(value);
+    }


암호화 된/되지 않은 텍스트 구분을 위한 정적 팩터리 메서드 생성
- Password.encrypt()와 Password.plain() 딱 봤을때 뭐가뭔지 혼동이 옴 (경험담)

Password는 인터페이스화 시키고 이를 구현한 EncodePassword, RawPassword 따로 생성
- 과한 설계처럼 느껴짐

암호화 작업을 Password 밖에서 수행
- 글자수 체크하는 등의 validate 작업도 Password 밖에서 수행해야함

암호화 관련 클래스를 의존 관계로 주입하고 encrypt() 메서드 따로 수행 필요 (현재 선택한 방법)

현재는 Password 값 객체가 가변이기 때문에 암호화된 값과 평문이 모두 들어갈 수 있는 구조에요. Password 객체를 사용하는 입장에서 객체 내부에 평문이 들어가있을지, 암호화된 값이 들어가있을지 예측할 수 있을까요?

Password를 단방향으로 암호화하는 이유는 평문을 보면 안 되기 때문이겠죠. 그래서 Password 객체가 갖고 있어야하는 값은 암호화된 값이라고 생각합니다. 평문은 최대한 빠르게 로직에서 제거하면 좋을 것 같아요.

이렇게 규약을 놓고 보면 정적팩토리 메서드도 나쁘지 않다고 생각합니다. 항상 암호화된 값을 갖는다고 하면 생성자로는 암호화된 값을 받고, 팩토리 메서드 plain으로부터는 평문을 받아서 복호화할 수 있다고 생각해요.

ddaaac · 2022-06-02T14:47:33Z

src/test/java/woowacourse/auth/acceptance/AuthAcceptanceTest.java

@@ -2,7 +2,6 @@

 import org.junit.jupiter.api.DisplayName;
 import org.junit.jupiter.api.Test;
-


AuthAcceptanceTest는 구현되어야하지 않나요?

Auth 관련 컨트롤러를 삭제하면서 같이 삭제되어야하던 클래스인데 깜빡한 것 같아요💦
이번에 리팩터링하며 AuthContoller가 다시 생겨 관련 부분 테스트 코드 추가했습니다

ddaaac · 2022-06-02T15:06:36Z

src/main/java/woowacourse/shoppingcart/ui/ControllerAdvice.java

    public ResponseEntity handleInvalidAccess(final RuntimeException e) {
        return ResponseEntity.badRequest().body(e.getMessage());
    }
+
+    @ExceptionHandler
+    @ResponseStatus(HttpStatus.BAD_REQUEST)
+    public ErrorResponse handleBadRequest(BadRequestException e) {
+        return new ErrorResponse(e.getMessage());
+    }


새로운 커스텀 예외 클래스가 추가될 때마다 ControllerAdvice가 변경될 것 같은데 해결할 수 있는 방법이 있을까요?

Bad Request를 내려주기 위한 예외, Not Found를 내려주기 위한 예외 등 크게 나누었기 때문에 이 외의 다른 상태 코드가 발생할 경우가 생기면 그때 커스텀 예외 클래스가 추가됩니다.
새로운 커스텀 예외 클래스가 추가될 일이 많이 없을거라 생각했어요

다만 범블비가 말한 문제에 대해서 생각해보다가 어떤 상태 코드를 반환할지 서비스에서 결정한다는 생각이 들었어요
어떤 예외가 발생한건지 바로 파악하기도 힘든 것 같고요

그래서 패스워드 불일치로 인한 예외 발생 시 아래 같은 클래스를 반환하고

public class PasswordMismatchException extends UnauthorizedException { //... }

핸들러 익셉션에서는 UnauthorizedException에 대해서 처리하도록 리팩터링 하였습니다!

잘 구현해주셨습니다 💯

모든 커스텀 예외의 부모 클래스를 두고 그 클래스가 메세지 + 상태코드를 가져도 좋을 것 같아요. 상태코드가 없다면 400으로 처리한다던지 하면 일반적으로 처리가 가능할 것 같네요.

ddaaac · 2022-06-02T15:10:46Z

src/main/java/woowacourse/shoppingcart/application/CustomerService.java

+    private CustomerEntity findCustomerById(Long customerId) {
+        return customerDao.findById(customerId)
+                .orElseThrow(() -> new NotFoundException(NO_CUSTOMER_ERROR));
+    }


전 주로 조회 로직은 find vs get 을 따라서 이름을 지어요.
원칙은 아니지만 이렇게 컨벤션을 잡고 네이밍을 하면 나중에 보기 편하더라구요 :)

ddaaac · 2022-06-02T15:12:24Z

src/main/java/woowacourse/shoppingcart/application/CustomerService.java

+        CustomerEntity customerEntity = customerDao.findByAccount(account)
+                .orElseThrow(() -> new NotFoundException(NO_CUSTOMER_ERROR));
+
+        if (!passwordEncoder.match(signinRequest.getPassword(), customerEntity.getPassword())) {
+            throw new UnauthorizedException(LOGIN_FAILED_ERROR);
+        }


getter가 보이면 로직을 도메인으로 넣을 수 있을지 고민해보시면 좋을 것 같아요.
CustomerEntity 대신에 Customer를 사용한다면 password를 객체 내부에서 비교하고 검증할 수 있지 않을까요?

- Customer의 불필요한 생성자 제거 - 테스트 코드 정적 팩토리 메서드 사용

yeon-06 · 2022-06-04T10:24:30Z

안녕하세요 범블비! 1차 피드백 반영하고 다시 코드리뷰 요청 보냅니다!
덕분에 로직이 깔끔해지는걸 느낄 수 있었습니다 감사합니다 ㅎㅎ
리팩터링하며 생긴 의문 사항이 있어 코멘트로 남겨둬요!

DTO <-> Domain, Entity <-> Domain의 변환은 누구의 책임일까요?

Domain이 넣으면 DTO가 많아질수록 Domain이 커져 DTO에 두었습니다
Domain의 로직이 필요 없는 경우에는 DTO -> Entity의 변환도 상관 없을까요? 현재는 로직 변환의 책임을 주기 애매해서 DTO <-> Domain <-> Entity 식으로 Domain을 거쳐야 변환이 가능하게 구현했습니다

API URL 앞에 /api/...를 붙이는건 컨벤션일까요?

다른 크루들과 이야기를 나누다보니 URL에 /api/customers/ ... 식으로 작성하신 분들이 많더라고요 이유를 물어보니 CORS 에러에서 /**와 같이 모든 요청을 허용하는게 보안적으로 문제가 있을 수 있다고 하셨어요 이 사유에 대해서는 납득되었는데 왜 하필 api 키워드를 앞에 붙였는지는 잘 모르겠더라고요😂 URL에도 앞에 뭘 붙여야한다, 어떤 구성으로 만들어야 한다 같은 컨벤션이 있나요??

ddaaac

안녕하세요 연로그 👋

리뷰 반영 잘 해주셨어요 💯

질문과 코멘트에 대한 답 남겼어요. 확인해주시고 다음 단계 진행해주세요!

ddaaac · 2022-06-05T11:09:34Z

src/main/java/woowacourse/shoppingcart/application/CustomerService.java

+    public void create(CustomerRequest customerRequest) {
+        if (customerDao.existsByAccount(customerRequest.getAccount())) {
+            throw new DuplicatedCustomerException();
+        }
+        Customer customer = customerRequest.toCustomer();
+        customerDao.save(CustomerEntity.from(customer));
+    }


DTO <-> Domain, Entity <-> Domain의 변환은 누구의 책임일까요?

Domain이 넣으면 DTO가 많아질수록 Domain이 커져 DTO에 두었습니다

Domain의 로직이 필요 없는 경우에는 DTO -> Entity의 변환도 상관 없을까요? 현재는 로직 변환의 책임을 주기 애매해서 DTO <-> Domain <-> Entity 식으로 Domain을 거쳐야 변환이 가능하게 구현했습니다

DTO <-> Domain의 경우 서비스 레이어가 dto를 파라미터로 받고 응답 타입으로 사용할 때는 서비스 레이어가 해주는 게 적당하다고 생각해요. 다만, 중복 코드가 발생하고 서비스 코드가 너무 길어진다면 DTO에서 변환해줘도 괜찮다고 생각합니다.

Domain <-> Entity 같은 경우에는 조금 원론적으로는 변환해주는 계층이 하나 더 있어야한다고 생각합니다. Service와 Dao 사이에 Repository 정도가 있으면 적당하겠네요(그렇다고 Repository가 변환만을 위한 계층이라는 건 아니에요. 오해하기 쉬운 부분이라 따로 남깁니다 😄 ). 하지만 지금 코드의 경우 domain과 entity가 단순하게 결합되어 있기 때문에 굳이 그럴 필요는 없다고 생각해요. 처음부터 CusomterEntity와 Customer가 분리될 필요도 없다고 생각합니다. 여튼 지금 정도로 두고, 나중에 다른 코드를 구현할 때 이 점을 염두해서 구현해보시면 좋을 것 같습니다 :)

ddaaac · 2022-06-05T11:11:59Z

src/main/java/woowacourse/shoppingcart/ui/CustomerController.java

+@RestController
 public class CustomerController {
+
+    private final CustomerService customerService;
+
+    public CustomerController(CustomerService customerService) {
+        this.customerService = customerService;
+    }
+
+    @PostMapping("/signup")


API URL 앞에 /api/...를 붙이는건 컨벤션일까요?

다른 크루들과 이야기를 나누다보니 URL에 /api/customers/ ... 식으로 작성하신 분들이 많더라고요 이유를 물어보니 CORS 에러에서 /**와 같이 모든 요청을 허용하는게 보안적으로 문제가 있을 수 있다고 하셨어요 이 사유에 대해서는 납득되었는데 왜 하필 api 키워드를 앞에 붙였는지는 잘 모르겠더라고요😂 URL에도 앞에 뭘 붙여야한다, 어떤 구성으로 만들어야 한다 같은 컨벤션이 있나요??

글쎄요... 백엔드 api를 사용하는 클라이언트에는 웹 뿐만 아니라 ios/android 등 다양한 클라이언트 들이 있는데요, 제가 알기로는 CORS는 웹에만 적용하면 됩니다. 그래서 웹 전용 api에만 붙이면 돼서 굳이 api를 붙일 필요가 있나 싶어요. 연로그가 불필요하다고 생각하신다면 넘어가도 될 부분 같네요 😄

yeon-06 and others added 30 commits May 29, 2022 15:52

docs: 1단계 요구 사항 정리

2332bf7

feat: 계정 소문자, 숫자 검증

5cfaa1c

docs: 회원 관련 기능 요구 사항 수정

441470e

feat: 계정 글자수 검증

f3fba4b

feat: 계정 공백 검증

1bf1ed6

feat: 닉네임 앞뒤 공백 제거

5ad79b9

feat: 닉네임 글자수 검증

8d12873

docs: 비밀번호 관련 요구사항 추가

049f311

feat: 비밀번호 대소문자, 숫자 조합 검증

3874c01

feat: 비밀번호 글자수 검증

bbb2150

- 비밀번호 조합 조건 수정 - 비밀번호 조합 테스트 케이스 추가

feat: 비밀번호 암호화

c432e9e

feat: 주소 앞뒤 공백 제거

ec69de4

feat: 주소 글자수 검증

55e6310

feat: 주소 빈 값 검증

5f04824

feat: 휴대폰 글자수 검증

67a94b1

feat: 휴대폰 숫자 검증

4f74cba

refactor: 도메인 코드 리팩터링

a114578

- 하드 코딩 제거 - 메서드 분리

refactor: vo 클래스 패키지 이동

26ed3aa

- 불필요한 import문 삭제

feat: 회원 생성

2a72f26

test: 회원 가입 요청 테스트 메서드 분리

ea8c7e1

feat: 계정 중복 검증

a3eb15d

feat: 회원 가입 예외 처리

b7ac768

build: 토큰 라이브러리 버전 수정

572a3a0

feat: jwt 라이브러리 마이그레이션

92d5a7c

feat: 로그인 구현

8387d4f

feat: 회원 조회

d6518e1

feat: 토큰 관련 인터셉터 추가

c6df52d

test: 토큰 관련 테스트 추가

41205a2

feat: 회원탈퇴

5cc0907

test: 테스트 메서드 분리

2ed3898

yhh1056 and others added 12 commits June 1, 2022 14:49

test: 존재하지 않는 사용자 조회 테스트

0a12e9a

feat: 회원 정보 수정

b24e4d3

fix: 토큰 전송을 안했을 때 예외 처리

4ab0667

test: 회원 정보 수정 예외 테스트 케이스

96f4e1b

refactor: 회원 관련 DAO 테스트 케이스

6502e12

- account로 조회하는 경우 Optional 반환 - TokenResponse 위치 변경 - 레거시 코드 username -> account 명칭 변경

test: 잘못된 테스트 코드 수정

c2dbc13

- 잘못된 예외 문구 수정

refactor: PhoneNumber 필드 변경

c384b31

test: 테스트 코드 리팩터링

5fd9ddd

- 하드 코딩 제거 - 메서드 이름 변경 - 메서드 분리 - given, when, then 분리 - 줄바꿈 추가/제거

style: 코드 리팩터링

cd5f5b3

- 메서드 이름 변경 - 클래스 이름 변경 - 줄바꿈 추가/제거

refactor: 하드 코딩 제거

e7eb40e

docs: 요구 사항 분리

38d3ccd

refactor: Password 생성자에서 암호화 로직 제거

9748cc1

ddaaac requested changes Jun 2, 2022

View reviewed changes

yeon-06 added 11 commits June 3, 2022 16:42

fix: CORS 에러 해결

975dfe0

refactor: auth와 customer API 분리

24482a2

refactor: 불필요한 bean 등록 제거

ef8ad72

refactor: extract 메서드의 파라미터 타입 변경

776e0ca

refactor: 중복 로직 제거

1ec28ea

refactor: 불필요한 ResponseEntity 제거

e58467f

test: {0} 문자열이 출력되는 현상 제거

f16cf55

refactor: Exception 공통으로 처리할 수 있도록 로직 변경

46b6e05

style: 메서드 이름 변경

fbb6b34

refactor: 비밀번호 정적 팩토리 메서드 도입

14384fe

- Customer의 불필요한 생성자 제거 - 테스트 코드 정적 팩토리 메서드 사용

refactor: Customer에서 내부에서 password 비교

8ec3f01

yeon-06 force-pushed the step1 branch from a44fe9b to 8ec3f01 Compare June 4, 2022 09:57

refactor: @transactional 추가

d392fa2

yeon-06 force-pushed the step1 branch from 3991d60 to d392fa2 Compare June 4, 2022 10:00

ddaaac approved these changes Jun 5, 2022

View reviewed changes

ddaaac merged commit f1afe52 into woowacourse:yeon-06 Jun 5, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[Spring 장바구니 - 1단계] 연로그(권시연) 미션 제출합니다. #31

[Spring 장바구니 - 1단계] 연로그(권시연) 미션 제출합니다. #31

yeon-06 commented Jun 1, 2022 •

edited

Loading

ddaaac left a comment

ddaaac Jun 2, 2022

yeon-06 Jun 3, 2022

ddaaac Jun 5, 2022

ddaaac Jun 2, 2022

yeon-06 Jun 3, 2022

yeon-06 Jun 3, 2022 •

edited

Loading

ddaaac Jun 5, 2022

ddaaac Jun 2, 2022

ddaaac Jun 2, 2022

ddaaac Jun 2, 2022

ddaaac Jun 2, 2022

yeon-06 Jun 3, 2022

ddaaac Jun 2, 2022

yeon-06 Jun 4, 2022 •

edited

Loading

ddaaac Jun 5, 2022

ddaaac Jun 2, 2022

ddaaac Jun 2, 2022

yeon-06 commented Jun 4, 2022

ddaaac left a comment

ddaaac Jun 5, 2022

ddaaac Jun 5, 2022

		@@ -2,7 +2,6 @@

		import org.junit.jupiter.api.DisplayName;
		import org.junit.jupiter.api.Test;

[Spring 장바구니 - 1단계] 연로그(권시연) 미션 제출합니다. #31

[Spring 장바구니 - 1단계] 연로그(권시연) 미션 제출합니다. #31

Conversation

yeon-06 commented Jun 1, 2022 • edited Loading

ddaaac left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

yeon-06 Jun 3, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

yeon-06 Jun 4, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

yeon-06 commented Jun 4, 2022

ddaaac left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

yeon-06 commented Jun 1, 2022 •

edited

Loading

yeon-06 Jun 3, 2022 •

edited

Loading

yeon-06 Jun 4, 2022 •

edited

Loading