예전부터 카카오 소셜로그인이나 그외 구글, 네이버, 애플 등의 소셜로그인을 구현할 때,
인가 토큰을 받고, 해당 토큰을 통해
사용자이름, 닉네임, 이메일, 연락처, 프로필 이미지와 같은 값들을 property로 받아와
사용자의 email을 pk로 user 엔티티를 구성했었다.
근데 24년 1월 2월 프로젝트 중,
카카오톡 소셜 로그인 기능을 구현하다보니 넘겨받는 property 정보가
카카오톡 기준 닉네임과 프로필 이미지 만으로 제한되는 문제가 발생했다.
그 이상의 정보를 사용자 동의를 통해 얻어내기 위해서는
사업자 번호(였나?)가 필요했다.
하지만 닉네임은 사용자의 고유값이 아니기 때문에
해당 정보를 pk로 처리할 수 없어 로그인 기능을 수정하고 수정하고 또 수정하다가
결국은 자체 로그인으로 구현을 했었다.
이번에 캡스톤 프로젝트를 앞두고 소셜로그인을 구현할 것 인지 말 것 인지에 관한 이야기가 나왔다.
난 당연히 실패한 경험이 있었기 때문에 바로 안될 것 같다고 얘기했지만
어쩌다 카카오톡 로그인 document를 찾아보니
인가토큰을 통해 사용자 target_id를 받아오는 api가 존재함을 알게되었다.
그래서 생각을 해보니 엔티티를 구성할때도 이메일을 pk로 두는 것 보다 target_id 값을 pk로 두는게 더 깔끔할 것 같았다.
그동안 로그인 구현할 때 document를 잘 읽어보지도 않고 블로그 등의 코드만 읽고 복붙했더니 이런 상황들이 발생했던 것 같다.
앞으로 어떤 기능을 구현하고자한다면 블로그나 gpt나 오픈소스 코드만에 의지하는게 아니라
가장 근본이 되는 document를 꼼꼼하게 잘 읽어야겠다고 생각했다.
이번 캡스톤에서 소셜로그인을 사용한다면 관련 document를 꼼꼼하게 읽고
직접 하나씩 구현을 해봐야겠다.
'일기' 카테고리의 다른 글
수퍼클래스 뽑아내기~ (3) | 2024.09.26 |
---|---|
캡스톤 매칭 결과 (0) | 2024.03.14 |
댓글