이메일 인증 회원가입 및 로그인 구현(2)

이메일 인증 회원가입 및 로그인 구현(2)

어떤 프로그램이든 회원가입 로그인은 기본적으로 구현해야 하는 부분 효과적인 방법인지는 모르겠지만 간단하게 회원가입과 로그인을 구현해보자. 첫번째 유저 데이터에 어떤 값이 들어갈지를 미리 설정해야 합니다. DayDream에는 회원가입 시 이메일, 비밀번호, 비밀번호 확인, 통신기기 인증추후 시간이 된다면., 나이, 키, 몸무게, 자기소개, 닉네임을 받고 있습니다. 그에 맞춰서 유저 모델을 설정해주면 됩니다. modelsuserModel.js 나는 특정 기능들을 유저관리자에 따라 제한해 줄 생각이기 때문에, role 필드도 추가해줬습니다.

로그인 전용 API 생성하기

우선 get을 썼던것처럼 동일하게 .post로 변경 후 api, user, signIn 세 개를 전달해 주면 http127.0.0.18080apiusersignIn으로 사용할 수 있을 것 같다. 단점은 입력한 파라미터를 어떠한 방식으로 받아서 쓸거냐인데. 파라미터 프로퍼티 정리를 보시면 URL로부터 nonstatic 한 파라미터를 가져온다고 합니다. 예를 들어 http127.0.0.18080apiusersignIn?key1value1key2value2같은 방식이면 아래의 코드처럼 파라미터를 가져다.

사용할 수 있을 것 같다. 우선 post로 key1, key2를 보낸다고 했을 때는 url에 키벨류가 포함되어서 리퀘스트에 알려지는 형태는 아닐 거고, 아마 xwwwformurlencoded 방식으로 인코딩 되어서 body에 전달될 것입니다.

소셜 로그인시 해당 소셜 정보를 바탕으로 회원 가입 처리 방법

수정 전과 수정 후의 유저 테이블

먼저 수정 전 유저 테이블은 다음과 같다. 현재 이 테이블 구조를 가져가면 소셜 로그인 회원과 기존 회원의 이메일이 겹칠 경우 이메일이 중복된 회원들을 판별할 수 있는 방법이 없습니다.. 아래는 수정된 유저 테이블입니다. 위 방식의 경우에는 다른 방식의 회원가입 회원들을 판별할 수 없는 문제가 있었으나 이 문제점을 해결하기 위해, 로그인 방법을 담는 컬럼을 추가하여 각 회원들을 구별하도록 하였습니다.

LOGINMETHOD라는 로그인 방법을 담는 컬럼을 추가하였고 기본값으로는 일반이라는 값이 담기도록했다.

이메일, 암호 Validation

기존에 앱에서도 위와 같이 정규식을 통해 이메일에 대한 유효성 검사를 실천하고 있었어요. 비슷하게 여기에서도 이 코드를 그대로 적용하면 될 것 같은데, 여기에서 한 가지 의문이 드는 점은 routes 부분에서 이런 코드를 위치시키기에는 부적절해 보였습니다. 이럴 때 쓰라고 Controller를 만들어둔 것 같은데. 대애충. 이렇게 하면 되려나. Error를 따로 만들어서 쓰려고 하다가 귀찮아서 문서를 보니 Abort라는 구조체를 제공하고 있었어요.

일반적으로 HTTP Response에서 상태별로 내려주는 코드 및 메시지를 사용할 수 있도록 잘 구현되어 있어서 추가 구현 없이 사용이 가능해 보였습니다. 클라이언트와 달리원래 에러 처리를 신경 쓰면서 개발하지는 않았어서 Vapor에서 공급하는 코드들은 기본적으로 에러를 염두에 두고 작성되어 있는 것 같다.

특정 유저에게만 해당되는 정보를 제공하기 위해

유저에게 가입로그인 절차는 번거로운 절차에요. 이미 경험해보셔서 그 번거로움을 아실거에요. 그럼에도 불구하고, 특정 고객이 식별되어, 그에 맞는 정보만 제공되어야 하는 서비스는 무조건적으로 가입로그인 절차를 두고 있어요. 그 이유는 고객의 명백한 데이터 관리를 위해 서버가 현재 접속한 고객이 예전에 가입한 고객인지를 인증 후, 그 고객에 맞는 정보를 제공해야하기 때문입니다. 식별되지 않은 이용자에게 다른 고객의 정보를 공급하는 것은 개인정보보호법 상 큰일나는 일이죠. 물론 서비스에 대한 고객의 신뢰도에도 문제가 생기고요. 예컨대 가입로그인 절차가 없는 모바일 쇼핑몰을 이용한다고 해보죠. 사용자가 여러개의 상품을 결제하고, 그 다음날 스마트폰을 잃어버렸어요. 그 다음날 결제한 상품이 언제 배송되는지 확인하려고 새로운 스마트폰으로 다시 앱을 설치하고 자신의 구매내역을 보려고 합니다.

Spring Security 설정

위 설정은 소셜 로그인만 적용한다면 시큐리티는 저렇게만 작성해도 충분합니다. 하지만 일반 로그인과 소셜 로그인 2가지 방법을 지원한다면 문제점이 발생할 것입니다. 그 이유는 아래의 포스팅에서 다루고자 합니다.

자주 묻는 질문