6/2 - 스터디

slee2·2022년 6월 2일
0

ToyProjectBoard

목록 보기
5/5

고민거리

  • 이메일을 이용한 회원가입의 경우
    • 이메일 인증을 마친 정식 회원이 존재하는 경우
    • 이메일 인증을 마치지 않은 회원이 존재하는 경우
    • 두 케이스를 어떻게 구분할 것인가

스터디 진행

  • Member 임시 저장을 Quartz를 이용한 스케쥴링
    • 이메일 가입을 하게 될때, 메일 인증을 하기 전에 Member에 임시 저장을 하게 된다.
    • 이는 Quartz를 이용하여 스케쥴링 설정이 되어 시간이 어느정도 지날때까지 인증을 하지 않게되면 회원이 삭제되는 로직
    • 이 방법을 사용하게 되니, 저장을 미리 해야한다는 불필요한 로직이 눈에 띔
  • 해결법
    • 메일을 전송하고 해당 Auth키를 Redis에서 잠시 저장을 한다.
    • 이 데이터는 만료기간을 처음부터 정하여 지나면 자동으로 삭제하게 된다.
    • Redis 값에 회원 정보를 통째로 저장
    • 이 방법을 사용하게 되면, 회원의 이메일 인증전까지 DB를 거치지 않게됨
    • Member에 인증을 했는지 안했는지 구분하는 boolean값 컬럼을 지워도 됨

그림으로 설명하자면

원래 로직이 이렇게 되고,

이렇게 간단하게 바뀌게 된다.

좀 더 효율적인 로직으로 발전하게 되었다.

@PostMapping("/member/signUp/email")
public void signUp(@Valid MemberDto memberDto, BindingResult bindingResult) throws JsonProcessingException {

	validation.validate(memberDto, bindingResult);

	if (bindingResult.hasErrors()) {
    	log.error("errors={}", bindingResult);
        return ;
    }

	// 원래 로직 - 멤버 DB로 미리 회원을 저장
	// memberService.signUp(memberDto);
    authKeyRepository.deleteAuth(memberDto.getEmail());

	//임의의 authKey 생성 & 이메일 발송
    String authKey = mss.sendAuthMail(memberDto.getEmail());
    memberDto.setAuthKey(authKey);
        
    // 바뀐 로직 - Redis에서 모든 회원정보를 저장
    // 이후에 인증을 완료하면 회원 DB에 새로 저장
    authKeyRepository.saveAuth(memberDto);
}

앞으로 할 일

  • Jacoco를 이용한 테스터 확인 및 단위 테스트 구현
  • Docker 설정에 대해 알아보기(local + aws)
  • (후순위) 이메일 암호화에 대해 생각해보기

0개의 댓글