토이 프로젝트 현황

• 스프링 시큐리티 소셜 로그인 마무리
• 스프링 시큐리티 일반 로그인 (email 인증)
  • 이메일 전송까지 완료
  • AuthKey 관리에 대해 고민이 생겨 보류중

스터디 진행

소셜 + 일반 이메일 병합에 대한 고민

소셜 로그인의 경우와, 일반 이메일 로그인을 어떻게 구분할 것인가.

• 소셜과 일반 이메일을 다른 컬럼으로 나눌 경우
  • 소셜 회원가입 이메일로 일반 이메일을 로그인할 경우를 고려해야됨
  • 컬럼이 일단 추가되므로 좋은 방법으로 고려되지는 않음
• 소셜 이메일과 일반 이메일을 하나의 컬럼에서 같이 사용할 경우
  • 소셜 로그인의 경우와 일반 로그인의 경우를 구분하는 enum이 필요
  • 소셜 로그인의 경우에는 비밀번호가 필요없게 됨
  • 확장성을 고려할 경우, 이렇게 하나의 컬럼으로 두는것이 용이해 보임

결과적으로 소셜 이메일과 일반 이메일을 하나의 컬럼으로 사용하게 됨

@Entity
@Getter
@NoArgsConstructor(access = AccessLevel.PROTECTED)
public class Member {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    @Column(name = "member_id")
    private Long id;

    private String email;
    private String password;
    private String nickname;
    private String role;
    private Boolean emailAuth;

    @Enumerated(EnumType.STRING)
    private MemberType memberType;
    ...

• memberType: NORMAL, SOCIAL 등으로 나눠서 어떤 로그인인지 구분짓게됨
  • 이로 인해 비밀번호에 대한 고민거리가 사라짐.
  • 소셜 로그인일 경우에는 이메일만 있어도 로그인 가능
  • 일반 로그인일 경우에는 이메일 + 비밀번호 일치 확인

토큰에 어떤 정보를 넣을 것인가에 대한 고민

현재 토큰에 이메일을 넣어둠. 하지만, 직접 토큰 작업으로 왔다갔다 해보니, 설정해야 하는 것들이 이것저것 생겨서 어떤 정보를 넣어야 할지 고민하게됨.

	...
    
public void doFilter(ServletRequest request, ServletResponse response,
		FilterChain chain) throws IOException, ServletException {
	String token = ((HttpServletRequest) request).getHeader("Auth");

	log.info("token={}", token);

	if (token != null && tokenService.verifyToken(token)) {
    	String email = tokenService.getUid(token);
        String role = tokenService.getRole(token);
        log.info("success");
		
        // 원래 role을 수동으로 넣었었지만,
        // 토큰에 role까지 넣어줌으로써 해당 회원의 role을 넣어줌
		Authentication auth = getAuthentication(email, role);
    	SecurityContextHolder.getContext().setAuthentication(auth);
    }
    chain.doFilter(request, response);
}

    ...

• doFilter이 토큰에서 이메일을 꺼내오고 이를 통해 인증을 만들어주는데, 이때 role을 수동으로 입력하게됨
  • 해당 회원의 role을 가져오기 위해서는 DB를 들려야하는데, 더 좋은 방법이 있어보임
  • 더 좋은 방법으로 회원의 email과 role을 토큰에 넣어두는 방법을 선택
• 컨트롤러에서 principal을 가져오면 email이 들어있으니, 어차피 DB에서 검색을 통해 해당 회원을 가져와야됨
  • 그렇다면 회원ID를 저장하는 것이 더 용이해보임

앞으로 할 일

• 이메일 인증할때, AuthKey를 랜덤으로 생성하여 DB에 저장하게 되는데, 이 키를 굳이 저장할 필요가 없어보여, 대신 해주는 redis를 사용하여 구현하기
• AuthKey의 만료기간이 되었을때, 삭제하는 스케쥴러를 등록하기 위해 quartz를 사용하기
• 특정 로그(log.error(), log중에 DB)를 파일로 저장하여 나중에도 확인 가능하도록 만들기