Closed osj3474 closed 1 year ago
하지만 이메일이 약관 선택 사항으로 예외 처리를 해주어야 합니다.
@osj3474 님, 요 부분이 어떤 의미인지 좀더 설명부탁드려도 될까요?
카카오는 이메일을 강제할 수가 없어서 이메일을 못 받는 경우가 있습니당...
카카오는 이메일을 강제할 수가 없어서 이메일을 못 받는 경우가 있습니당...
@osj3474 헉... 😮
해당 작업을 진행 중인데요~! 현재 저희 운영팀을 제외하고 일반 사용자들은 소셜 로그인으로만 로그인이 진행됩니다. 이 때, 사용자를 식별하는 키는 이메일이 아닌 위의 소셜 로그인 회원번호 입니다. 그렇게 되면 이메일이 unique 해야할지 고민이 됩니다. (기존에 가입한 적이 있는 사용자인지 판단하는 로직이 소셜 로그인 회원번호로 체크를 하다보니 이메일 중복이 발생하는 경우를 확인하였고 함께 논의해보면 좋겠다고 생각되어 여쭤봅니다.)
기존에 남아있던 email, password를 넘겨서 로그인하는 api는 user_role을 추가하여 관리자만 허용할 수 있도록 리팩토링 예정인 api입니다.
@doljae 님, @mean-ji 님 두 분 다 코멘트 남겨주시면 감사하겠습니다~~! => 이메일 unique 해야한다 vs 그럴 필요는 없다. (근거와 함께)
저는 사용자는 하나의 계정만 만들 수 있다
라는 제약만 줄 수 있다면 이메일의 unique 유무는 상관없을 것 같습니다.
이 때, 사용자를 식별하는 키는 이메일이 아닌 위의 소셜 로그인 회원번호 입니다.
다만 식별자로 사용할 예정인 소셜 로그인 회원 번호
는 추후에 변경될 일이 없는 고유한 값인지에 대한 확인은 필요할 것 같습니다.
확실하지 않지만 이전에 사용자는 하나의 계정만 만들 수 있다
라는 제약을 주는 것으로 이야기가 된 것으로 기억하고 있는데요, 이 경우 email을 unique하게 하지 않고 위 제약
을 줄 수 있어야할 것 같습니다. 만일 그런 제약을 두지 않기로 이야기가 되었다면 문제 없을 것 같습니다.
이메일로 중복 체크를 하던 것들을 소셜 로그인 회원번호로 중복 체크 하도록 한다면 소셜 로그인 회원번호가 unique 하기 때문에, 이메일은 중복 되어도 괜찮을 것 같다는 생각이 듭니다.
완료되어 종료합니다~!
기존에는 "이메일 정보" 를 기반으로 기존에 가입한 사용자인지를 구별했습니다. 하지만 이메일이 약관 선택 사항으로 예외 처리를 해주어야 합니다. 이메일을 필수 정보로 획득하지 않고, 리소스 서버가 내려주는 사용자 식별 값을 DB에 저장하여 해당 역할을 하고자 합니다.
먼저 소셜 로그인 후 내려주는 사용자 정보 중에 회원 식별 값을 아래 링크를 기반으로 확인하여 작업해보고자 합니다.
< 각 서비스 API 소개 >
하지만 정확한 회원 식별값의 길이에 대해서는 찾지 못하였고, 제 회원 번호를 기준으로 길이값을 공유드립니다.
oauth_ci 라는 컬럼을 만들어서 관리할 경우, 정확한 길이 값에 대한 설명을 찾지 못하여서 varchar를 50으로 하려고 합니다.