[임시 비밀번호 발급 및 전송] 임시 비밀번호 발급 및 전송 비즈니스 로직/API 구성(#35) #40

Minjae-An · 2024-03-14T09:35:31Z

작업 대상

서비스 사용 정규식(ServiceRegex )
임시 비밀번호 발급 기능(TemporaryPasswordGenerator)
spring mail 사용을 위한 설정(MailConfig )
이메일 전송 로직(EmailService )
임시 비밀번호 전송 비즈니스 로직(LoginService )
임시 비밀번호 전송 API(LoginController )

📄 작업 내용

서비스에 사용하는 정규식들을 한 눈에 관리하기 위한 enum 정의
비밀번호 정규식 조건을 충족하는 랜덤한 임시 비밀번호 생성 로직 구현
spring mail에서 제공하는 이메일 전송 기능(JavaMailSender ) 사용을 위한 설정 정의
임시 비밀번호 발급 및 전송 비즈니스 로직
1. 요청 이메일 기반 사용자 조회
2. 임시 비밀번호 생성
3. 사용자 비밀번호, 임시 비밀번호로 변경
4. 임시 비밀번호 발급 메일 전송
임시 비밀번호 발급 및 전송 API 구현

임시 비밀번호를 암호화하는 로직, 비동기 처리 로직은 추후에 구현 예정

🙋🏻 주의 사항

build.gradle 에 spring mail 모듈에 대한 의존성을 추가하였습니다.
이메일 전송 기능은 Gmail SMTP 서버를 통해 구현했습니다. 이에 따라 application.properties 와 application.yml 에 해당 서버를 이용하는데 필요한 속성들을 정의했으니 참고해주세요.

📎 관련 이슈

springframwork.util의 Javadoc에서 해당 패키지에서 제공하는 StringUtils보다 복합적인 유틸 기능을 필요로 할 시 apache.commons.lang에서 제공하는 유틸 클래스를 사용할 것을 언급하고 있음
이에 임시 비밀번호 생성 로직에 spring boot에서 기본적으로 제공하는 apache.commons.lang3.RandomStringUtils를 사용
이메일을 발송하는 로직이 동기 방식으로 동작할 경우 SMTP 서버에서 서비스 서버가 응답을 받은 후 클라이언트에 응답
이로 인해 응답 시간이 17~20초로 매우 길게 측정됨
비동기 처리를 하면 시간을 훨씬 단축되나 해당 로직이 별도의 쓰레드에 실행됨(컨텍스트가 다르다)
이에 따라 기존 ExceptionAdvice에서 비동기 로직에서 발생한 예외를 커스텀 처리할 수 없음
추후에 현재의 일관성 있는 예외 응답 형식을 비동기 예외에 대해서도 적용할 방법을 찾는다면 비동기 처리 예정

레퍼런스

보낼 화살 수를 담은 요청 DTO 정의

- 화살 송수신 내역 repository 정의 - 보낸 사용자, 받은 사용자를 통해 내역 존재 여부를 확인하는 로직 구현

보낸 사용자, 받은 사용자를 통해 송수신 내역 존재 여부를 확인하는 로직 구현

다음 상황들에 대한 예외 enum을 정의하였다. - 자기 자신에게 화살을 보내는 경우 - 이미 화살을 보낸 사용자인 경우 - 가진 화살 수가 부족해 화살을 보낼 수 없는 경우

감소하려는 화살 수가 사용자가 보유한 화살 수보다 클 경우 예외 발생

화살 보내기 비즈니스 로직은 다음 과정을 거친다. 1. 자기 자신에게 화살을 보내는 상황 검증 2. 화살을 보낸 사용자에게 또 보내는 상황 검증 3. 화살 내역 저장 4. 보내는 사용자 화살 감소, 화살이 부족할 경우 예외 발생(과정 3 롤백) 5. 받는 사용자 화살 증가

- query, command를 service, repository를 중개하는 별도의 계층을 통해 구분 - 이에 따라 기존 command repository 삭제 - 기존 command repository 사용 위치, 화살 command로 대체

# Conflicts: # be/src/main/java/yeonba/be/arrow/repository/ArrowCommand.java # be/src/main/java/yeonba/be/arrow/service/ArrowService.java # be/src/main/java/yeonba/be/exception/CommonException.java # be/src/main/java/yeonba/be/user/entity/User.java

서로 대치되는 작업을 수행하는 상황을 잘 표현할 수 있도록 메서드 이름 수정

- 이미 화살을 보낸 사용자 예외 - 화살이 부족하여 화살을 보낼 수 없는 예외

가독성 향상을 위해 간단한 이름을 수정

dev 브랜치 작업 내역 병합에 따른 코드 배치 수정

좀 더 명확하게 대치되는 의미를 나타낼 수 있도록 화살을 받는 사용자 ID 파라미터 이름을 receiverId로 수정

- 이름 칼럼 추가 - 테스트시 활용 가능한 생성자 추가

- 래퍼 타입 필드들 기본 타입으로 변경 - 프로필 사진 URL 리스트 필드 추가 - 사용자가 가진 총 화살 수 필드 추가 - 음주 성향, 흡연 성향 필드 추가 - 코드 정렬

- 레퍼런스 타입 not null 필드들, Column 어노테이션 사용 명시 - salt 필드 추가 - 생성 일시, 최종 수정 일시 필드 추가 - JpaAuditing 활용, 생성/최종 수정 일시 필드들 엔티티 저장시 자동 설정 - 새로운 생성자 구성

프로필을 조회하는 사용자 ID의 경우 상대방이 화살을 보넀던 사용자인지 확인하기 위해 파라미터로 받는다.

- 요구사항 변경에 따라 음주 성향, 흡연 성향 필드 삭제 - 성별 정보 제공 메서드 추가

- 음주 성향, 흡연 성향 필드 삭제 - 성별 필드 추가

- 음주 성향, 흡연 성향 필드 삭제 - 생성자 성별 필드 설정 로직 수정 - 코드 정렬

- 음주 성향, 흡연 성향 삭제 - 성별 정보 응답에 포함토록 수정 - 코드 정렬

# Conflicts: # be/src/main/java/yeonba/be/arrow/service/ArrowService.java # be/src/main/java/yeonba/be/user/controller/UserController.java # be/src/main/java/yeonba/be/user/entity/User.java

# Conflicts: # be/src/main/java/yeonba/be/user/entity/User.java

dev 브랜치 작업 내역 병합에 따른 코드 재배치

acceptor-gyu

코드, 팀 컨벤션 생각해주세요. 테스트 코드가 없기 때문에 급하게 구현만 하는 것보다 postman으로 테스트도 성공/실패 케이스 모두 해보시고 PR 올려주시기 바랍니다.

acceptor-gyu · 2024-03-15T01:54:41Z

be/src/main/resources/application.yml

+  mail:
+    host: smtp.gmail.com
+    port: 587
+    username: ${GOOGLE_SMTP_USERNAME}
+    password: ${GOOGLE_SMTP_PASSWORD}


secret의 경우 properties에서 관리하기로 했는데 yml에 작성하신 이유는 무엇인가요?

secret이라는 게 노출되었을 경우 보안적으로 위험할 수 있는 대상들을 지칭한다고 생각했습니다. smtp 서비스 제공 호스트와 그에 따른 포트의 경우 지극히 공개적인 값이라 굳이 application.properties로 관리하지 않고 YAML 파일에 바로 명시하였습니다. 하지만 말씀해주신 부분을 생각해보면 application.properties에서 일관성 있게 관리하는 것이 맞다고 생각됩니다. 수정하겠습니다.

acceptor-gyu · 2024-03-15T01:58:44Z

be/src/main/java/yeonba/be/util/TemporaryPasswordGenerator.java

+      if(result.matches(pattern)){
+
+        return result;
+      }
+    }
+  }


return 문이 없습니다.

acceptor-gyu · 2024-03-15T02:00:38Z

be/src/main/java/yeonba/be/util/TemporaryPasswordGenerator.java

+  public static String generatePassword(){
+    String pattern = ServiceRegex.PASSWORD.getPattern();
+    SecureRandom random = new SecureRandom();
+    StringBuilder sb = new StringBuilder();
+
+    int length = MIN_LENGTH + random.nextInt(MAX_LENGTH - MIN_LENGTH+1);
+
+    while(true){
+      sb.setLength(0);
+      for(int i=0; i<length; i++){
+        int choice = random.nextInt(4);
+
+        if(choice == 0){
+          sb.append(getRandomCharacterFromSrc(LOWER, random));
+          continue;
+        }
+
+        if(choice==1){
+          sb.append(getRandomCharacterFromSrc(UPPER, random));
+          continue;
+        }
+
+        if(choice==2){
+          sb.append(getRandomCharacterFromSrc(DIGITS, random));
+          continue;
+        }
+
+        sb.append(getRandomCharacterFromSrc(SPECIAL, random));
+      }
+
+      String result = sb.toString();
+      if(result.matches(pattern)){
+
+        return result;
+      }
+    }
+  }


depth가 너무 깊어 어디부터 어디까지 하나의 블록인지 구분하기가 어려운데 아래와 같은 방식은 어떤가요?

Suggested change

public static String generatePassword(){

String pattern = ServiceRegex.PASSWORD.getPattern();

SecureRandom random = new SecureRandom();

StringBuilder sb = new StringBuilder();

int length = MIN_LENGTH + random.nextInt(MAX_LENGTH - MIN_LENGTH+1);

while(true){

sb.setLength(0);

for(int i=0; i<length; i++){

int choice = random.nextInt(4);

if(choice == 0){

sb.append(getRandomCharacterFromSrc(LOWER, random));

continue;

}

if(choice==1){

sb.append(getRandomCharacterFromSrc(UPPER, random));

continue;

}

if(choice==2){

sb.append(getRandomCharacterFromSrc(DIGITS, random));

continue;

}

sb.append(getRandomCharacterFromSrc(SPECIAL, random));

}

String result = sb.toString();

if(result.matches(pattern)){

return result;

}

}

}

public static String generatePassword() {

StringBuilder password = new StringBuilder(MIN_LENGTH);

Random random = new Random();

// 각 카테고리에서 최소 하나의 문자를 선택

password.append(LOWER_CASES.charAt(random.nextInt(LOWER_CASES.length())));

password.append(UPPER_CASES.charAt(random.nextInt(UPPER_CASES.length())));

password.append(DIGITS.charAt(random.nextInt(DIGITS.length())));

password.append(SPECIAL_CHARS.charAt(random.nextInt(SPECIAL_CHARS.length())));

// 모든 가능한 문자를 포함하는 문자열

String allPossibleChars = LOWER_CASES + UPPER_CASES + DIGITS + SPECIAL_CHARS;

// 나머지 길이를 채우기

for (int i = 4; i < MIN_LENGTH; i++) {

password.append(allPossibleChars.charAt(random.nextInt(allPossibleChars.length())));

}

// 문자열 섞기

ArrayList<Character> pwdChars = new ArrayList<>();

for (char c : password.toString().toCharArray()) {

pwdChars.add(c);

}

Collections.shuffle(pwdChars);

StringBuilder finalPassword = new StringBuilder();

for (char c : pwdChars) {

finalPassword.append(c);

}

return finalPassword.toString();

}

위 구성 형태가 더 깔끔하고 가독성도 좋은 것 같습니다. 앞서 언급했던 return문 관련 코멘트도 고려하여 수정하겠습니다.

acceptor-gyu · 2024-03-15T02:01:29Z

be/src/main/java/yeonba/be/util/TemporaryPasswordGenerator.java

+    while(true){
+      sb.setLength(0);
+      for(int i=0; i<length; i++){
+        int choice = random.nextInt(4);
+
+        if(choice == 0){
+          sb.append(getRandomCharacterFromSrc(LOWER, random));
+          continue;
+        }
+
+        if(choice==1){
+          sb.append(getRandomCharacterFromSrc(UPPER, random));
+          continue;
+        }
+
+        if(choice==2){


코드 컨벤션 생각해주세요.

수정하겠습니다! 앞으로 유의하겠습니다.

임시 비밀번호는 다음 과정을 거쳐 생성된다. 1. 각 카테고리(영어 대소문자, 숫자, 특수문자)에서 한 글자씩 랜덤 선택 2. 모든 가능한 문자를 포함하는 문자열 형성 3. 앞서 생성한 문자열에서 나머지 길이를 채울 문자 랜덤 선택 4. 선택된 문자들 섞기 5. 최종 임시 비밀번호 생성 - 랜덤한 문자를 선택하는 부분은 spring boot에서 기본 제공되는 RandomStringUtils를 활용 - 문자열을 섞는 부분에서 shuffle을 위해 가변 컬렉션을 생성하려 새로운 List 할당

메일 서비스 제공 호스트와 포트 번호도 application.properties에서 관리하는 형태로 수정

acceptor-gyu

제가 잘 몰라서 그러는데 spring mail을 사용하려면 application.yml 파일에
spring:
mail:
host:
...
과 같은 형식이 들어가야 하는 건가요?

acceptor-gyu · 2024-03-18T01:39:04Z

be/src/main/java/yeonba/be/util/EmailService.java

+      String subject,
+      String text){


Suggested change

String subject,

String text){

String subject,

String text) {

acceptor-gyu · 2024-03-18T01:39:55Z

be/src/main/java/yeonba/be/util/ServiceRegex.java

+public enum ServiceRegex {
+
+  EMAIL("[a-zA-Z0-9_!#$%&’*+/=?`{|}~^.-]+@[a-zA-Z0-9.-]+$"),
+  PASSWORD("^(?=.*[a-zA-Z])(?=.*\\d)(?=.*[~#@!]).{8,20}$");


조금 더 직관적인 이름을 사용하는 것은 어떤가요?

클래스명 수정하고 반영하겠습니다!

acceptor-gyu · 2024-03-18T01:40:35Z

be/src/main/resources/application.yml

+  mail:
+    host: ${GOOGLE_SMTP_HOST}
+    port: ${GOOGLE_SMTP_PORT}
+    username: ${GOOGLE_SMTP_USERNAME}
+    password: ${GOOGLE_SMTP_PASSWORD}


Suggested change

mail:

host: ${GOOGLE_SMTP_HOST}

port: ${GOOGLE_SMTP_PORT}

username: ${GOOGLE_SMTP_USERNAME}

password: ${GOOGLE_SMTP_PASSWORD}

acceptor-gyu · 2024-03-18T01:42:30Z

be/src/main/java/yeonba/be/config/MailConfig.java

+  @Value("${spring.mail.host}")
+  private String serverHost;
+
+  @Value("${spring.mail.port}")
+  private int serverPort;
+
+  @Value("${spring.mail.username}")
+  private String username;
+
+  @Value("${spring.mail.password}")
+  private String password;


Suggested change

@Value("${spring.mail.host}")

private String serverHost;

@Value("${spring.mail.port}")

private int serverPort;

@Value("${spring.mail.username}")

private String username;

@Value("${spring.mail.password}")

private String password;

@Value("${GOOGLE_SMTP_HOST}")

private String serverHost;

@Value("${GOOGLE_SMTP_PORT}")

private int serverPort;

@Value("${GOOGLE_SMTP_USERNAME}")

private String username;

@Value("${GOOGLE_SMTP_PASSWORD}")

private String password;

acceptor-gyu · 2024-03-18T01:44:31Z

be/src/main/java/yeonba/be/login/controller/LoginController.java

+      @RequestBody @Valid UserPasswordInquiryRequest request) {
+


제가 생각할 때는 @RequestBody UserPasswordInquiryRequest를 하나로 보고 이것을 @Valid로 검증한다라는 의미로 생각하는게 자연스러운데 어떻게 생각하시나요?

Suggested change

@RequestBody @Valid UserPasswordInquiryRequest request) {

@Valid @RequestBody UserPasswordInquiryRequest request) {

로직 흐름상 더 자연스러운 것 같습니다. 반영하겠습니다!

# Conflicts: # be/src/main/java/yeonba/be/mypage/dto/response/UserProfileDetailResponse.java # be/src/main/java/yeonba/be/user/dto/response/UserProfileResponse.java # be/src/main/java/yeonba/be/user/entity/User.java

Minjae-An · 2024-03-18T06:29:48Z

application.yml에서 메일 관련 프로퍼티들을 따로 관리하지 않으면, 메일 전송과 관련된 코드에서 해당 설정들이 하드 코딩된 형태로 작성되게 됩니다. 따라서 application.yml에 값을 명시하고 가져다 쓰는 방식이 유지보수에 용이하다고 판단하여 이런 형태로 구성하였습니다.

어플리케이션 전역에서 검증을 위해 사용되는 정규식들을 모아놓는 용도를 잘 표현하기 위해 클래스명 수정

사용자 지정 속성을 사용한다는 맥락을 잘 나타낼 수 있도록 수정

@Valid

요청 바디에서 읽어온 데이터를 검증한다는 흐름에서 @Valid 어노테이션이 @RequestBody보다 먼저 위치하도록 코드 수정

acceptor-gyu · 2024-03-18T09:18:18Z

application.yml에서 메일 관련 프로퍼티들을 따로 관리하지 않으면, 메일 전송과 관련된 코드에서 해당 설정들이 하드 코딩된 형태로 작성되게 됩니다. 따라서 application.yml에 값을 명시하고 가져다 쓰는 방식이 유지보수에 용이하다고 판단하여 이런 형태로 구성하였습니다.

application.properties에서 관리하는데 application.yml에서도 관리해야 하는 이유가 있는지 궁금합니다.

Minjae-An · 2024-03-21T13:08:38Z

application.properties와 application.yml의 우선순위에 관해 제가 잘못 인식하고 있는 부분이 있어 보완하였습니다. 감사합니다!

acceptor-gyu · 2024-03-23T12:58:48Z

be/src/main/java/yeonba/be/login/service/LoginService.java

+  /*
+  임시 비밀번호는 다음 과정을 거친다.
+    1. 요청 이메일 기반 사용자 조회
+    2. 임시 비밀번호 생성
+    3. 사용자 비밀번호, 임시 비밀번호로 변경
+    4. 임시 비밀번호 발급 메일 전송
+   */


Minjae-An added 30 commits March 9, 2024 17:16

feat: 화살 보내기 요청 DTO 추가(#24)

d8cc31d

보낼 화살 수를 담은 요청 DTO 정의

feat: 확살 송수신 내역 repository, 내역 확인 로직 추가(#24)

9b49093

- 화살 송수신 내역 repository 정의 - 보낸 사용자, 받은 사용자를 통해 내역 존재 여부를 확인하는 로직 구현

feat: 화살 송수신 내역 존재 여부 확인 로직 추가(#24)

e953b85

보낸 사용자, 받은 사용자를 통해 송수신 내역 존재 여부를 확인하는 로직 구현

feat: 화살 송수신 내역 저장 기능 구현(#24)

7a7b7c3

feat: 화살 관련 예외 enum 정의(#24)

d781de3

다음 상황들에 대한 예외 enum을 정의하였다. - 자기 자신에게 화살을 보내는 경우 - 이미 화살을 보낸 사용자인 경우 - 가진 화살 수가 부족해 화살을 보낼 수 없는 경우

feat: 사용자 화살 감소 로직 추가(#24)

8aad1e4

감소하려는 화살 수가 사용자가 보유한 화살 수보다 클 경우 예외 발생

refactor: 생성 시간 필드, 불필요한 업데이트 불가 DDL 속성 삭제(#24)

7dd07aa

feat: 화살 보내기 API 구현(#24)

9a4cae0

refactor: 화살 command repository 삭제(#24)

52995c4

- query, command를 service, repository를 중개하는 별도의 계층을 통해 구분 - 이에 따라 기존 command repository 삭제 - 기존 command repository 사용 위치, 화살 command로 대체

refactor: 코드 정렬 수정(#24)

a2c164d

refactor: 사용자 화살 증감 메서드 이름 수정(#24)

6c7ff1d

서로 대치되는 작업을 수행하는 상황을 잘 표현할 수 있도록 메서드 이름 수정

feat: 화살 관련 예외 enum 추가(#24)

01f3138

- 이미 화살을 보낸 사용자 예외 - 화살이 부족하여 화살을 보낼 수 없는 예외

refactor: 화살 내역 존재 여부 확인 메서드 이름 수정(#24)

95c99d8

가독성 향상을 위해 간단한 이름을 수정

refactor: 코드 배치 수정(#24)

672f7bb

dev 브랜치 작업 내역 병합에 따른 코드 배치 수정

refactor: 화살 보내기 API 파라미터 이름 수정(#24)

f25c26f

좀 더 명확하게 대치되는 의미를 나타낼 수 있도록 화살을 받는 사용자 ID 파라미터 이름을 receiverId로 수정

refactor: 컨벤션에 맞게 코드 배치 수정(#24)

4d26a15

feat: 이름 칼럼, 생성자 추가(#27)

7efedf9

- 이름 칼럼 추가 - 테스트시 활용 가능한 생성자 추가

feat: 상대 프로필 응답 DTO 수정(#27)

d77dae4

- 래퍼 타입 필드들 기본 타입으로 변경 - 프로필 사진 URL 리스트 필드 추가 - 사용자가 가진 총 화살 수 필드 추가 - 음주 성향, 흡연 성향 필드 추가 - 코드 정렬

feat: 상대 프로필 조회 비즈니스 로직 추가(#27)

fa4204d

프로필을 조회하는 사용자 ID의 경우 상대방이 화살을 보넀던 사용자인지 확인하기 위해 파라미터로 받는다.

feat: 상대 프로필 API 구현 및 코드 정렬(#27)

87ec03e

feat: 사용자 엔티티 수정(#27)

e6f7eb1

- 요구사항 변경에 따라 음주 성향, 흡연 성향 필드 삭제 - 성별 정보 제공 메서드 추가

feat: 사용자 프로필 응답 DTO 수정(#27)

4aba46d

- 음주 성향, 흡연 성향 필드 삭제 - 성별 필드 추가

feat: 사용자 프로필 상세 응답 DTO 수정(#27)

6cc2cb6

- 음주 성향, 흡연 성향 필드 삭제 - 생성자 성별 필드 설정 로직 수정 - 코드 정렬

feat: 사용자 프로필 조회 비즈니스 로직 수정(#27)

1d75218

- 음주 성향, 흡연 성향 삭제 - 성별 정보 응답에 포함토록 수정 - 코드 정렬

chore: spring mail 종속성 추가(#35)

4e54bfd

chore: Gmail SMTP 사용을 위한 설정 추가(#35)

ba20da8

feat: 이메일 기반 사용자 조회 로직 추가(#35)

0d4b90f

Merge branch 'dev' into feat/#35-send-temporary-password

7216f5d

# Conflicts: # be/src/main/java/yeonba/be/arrow/service/ArrowService.java # be/src/main/java/yeonba/be/user/controller/UserController.java # be/src/main/java/yeonba/be/user/entity/User.java

Minjae-An added the ✨ feat 새로운 기능 추가 label Mar 14, 2024

Minjae-An requested a review from acceptor-gyu March 14, 2024 09:35

Minjae-An self-assigned this Mar 14, 2024

Minjae-An linked an issue Mar 14, 2024 that may be closed by this pull request

[BE] 임시 비밀번호 발급 및 전송 비즈니스 로직 및 API 구성 #35

Closed

Merge branch 'dev' into feat/#35-send-temporary-password

52373f1

# Conflicts: # be/src/main/java/yeonba/be/user/entity/User.java

Minjae-An closed this Mar 14, 2024

Minjae-An reopened this Mar 14, 2024

Minjae-An added 3 commits March 14, 2024 20:02

Merge branch 'dev' into feat/#35-send-temporary-password

3cd825f

refactor: 병합에 따른 코드 재배치(#35)

50b9982

dev 브랜치 작업 내역 병합에 따른 코드 재배치

refactor: 병합에 따른 코드 재배치(#35)

45adb7a

dev 브랜치 작업 내역 병합에 따른 코드 재배치

acceptor-gyu reviewed Mar 15, 2024

View reviewed changes

Minjae-An added 3 commits March 15, 2024 15:07

chore: application.yml 메일 관련 속성 수정(#35)

d514a96

메일 서비스 제공 호스트와 포트 번호도 application.properties에서 관리하는 형태로 수정

feat: 비밀번호 찾기 API, 이메일 형식 검증 추가(#35)

78b6f1d

acceptor-gyu reviewed Mar 18, 2024

View reviewed changes

Merge branch 'dev' into feat/#35-send-temporary-password

76d2eb1

# Conflicts: # be/src/main/java/yeonba/be/mypage/dto/response/UserProfileDetailResponse.java # be/src/main/java/yeonba/be/user/dto/response/UserProfileResponse.java # be/src/main/java/yeonba/be/user/entity/User.java

Minjae-An added 5 commits March 18, 2024 15:34

refactor: 클래스 이름 수정(#35)

caeea54

어플리케이션 전역에서 검증을 위해 사용되는 정규식들을 모아놓는 용도를 잘 표현하기 위해 클래스명 수정

chore: application.yml 내용 정렬(#35)

0905fdb

refactor: 외부 설정 필드 주입 형태 수정(#35)

bb589e0

사용자 지정 속성을 사용한다는 맥락을 잘 나타낼 수 있도록 수정

refactor: 외부 설정 필드 주입 형태 수정(#35)

8708095

refactor: 파라미터 어노테이션 순서 수정(#35)

2d78b00

요청 바디에서 읽어온 데이터를 검증한다는 흐름에서 @Valid 어노테이션이 @RequestBody보다 먼저 위치하도록 코드 수정

Minjae-An added 2 commits March 21, 2024 22:01

refactor: 잘못된 들여쓰기 수정을 위한 코드 정렬(#8)

947115a

refactor: 불필요한 spring-mail 관련 설정 삭제(#8)

be5153e

refactor: 잘못된 들여쓰기 수정, 코드 정렬(#35)

7ea89d0

acceptor-gyu approved these changes Mar 23, 2024

View reviewed changes

acceptor-gyu merged commit afa1330 into dev Mar 23, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[임시 비밀번호 발급 및 전송] 임시 비밀번호 발급 및 전송 비즈니스 로직/API 구성(#35) #40

[임시 비밀번호 발급 및 전송] 임시 비밀번호 발급 및 전송 비즈니스 로직/API 구성(#35) #40

Minjae-An commented Mar 14, 2024 •

edited

Loading

acceptor-gyu left a comment

acceptor-gyu Mar 15, 2024

Minjae-An Mar 15, 2024

acceptor-gyu Mar 15, 2024

acceptor-gyu Mar 15, 2024

Minjae-An Mar 15, 2024

acceptor-gyu Mar 15, 2024

Minjae-An Mar 15, 2024

acceptor-gyu left a comment

acceptor-gyu Mar 18, 2024

acceptor-gyu Mar 18, 2024

Minjae-An Mar 18, 2024

acceptor-gyu Mar 18, 2024

acceptor-gyu Mar 18, 2024

acceptor-gyu Mar 18, 2024

Minjae-An Mar 18, 2024

Minjae-An commented Mar 18, 2024

acceptor-gyu commented Mar 18, 2024

Minjae-An commented Mar 21, 2024

acceptor-gyu Mar 23, 2024

	@RequestBody @Valid UserPasswordInquiryRequest request) {
	@Valid @RequestBody UserPasswordInquiryRequest request) {

[임시 비밀번호 발급 및 전송] 임시 비밀번호 발급 및 전송 비즈니스 로직/API 구성(#35) #40

[임시 비밀번호 발급 및 전송] 임시 비밀번호 발급 및 전송 비즈니스 로직/API 구성(#35) #40

Conversation

Minjae-An commented Mar 14, 2024 • edited Loading

작업 대상

📄 작업 내용

🙋🏻 주의 사항

📎 관련 이슈

레퍼런스

acceptor-gyu 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

Choose a reason for hiding this comment

Choose a reason for hiding this comment

acceptor-gyu 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

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Minjae-An commented Mar 18, 2024

acceptor-gyu commented Mar 18, 2024

Minjae-An commented Mar 21, 2024

Choose a reason for hiding this comment

Minjae-An commented Mar 14, 2024 •

edited

Loading