/users API 리팩토링

[chang12]

@LeeJeongYeop

/facebook-auth

• status / data 포맷으로 되어있는 걸 변경할 필요가 있지 않을까 싶습니다.
• Client와 access_token 주고받는 과정에서 가능한 모든 시나리오를 분석
• 분석한 시나리오를 빠짐없이 구현

/

• 클라이언트가 유저의 연령대 정보를 얻고싶어하는 경우가 있다고 합니다. GET method의 처리도 필요해보입니다.

[chang12]

age 필드 update/retrieve 작업이 필요하니 DRF의 RetrieveUpdate CBV를 활용하면 좋을 듯 합니다.

[chang12]

@LeeJeongYeop
fb_id, gender, age 값을 PATCH로 갱신할 수 있도록 코드를 수정하였습니다.

[chang12]

이에 맞춰 API 스프레드시트 문서도 수정하였습니다.

[chang12]

• 클라이언트가 페이스북 로그인을 통해 어떤 데이터를 얻는가?
• 클라이언트가 서버에게 어떤 데이터를 보내는가?
• 서버는 어떤 데이터를 만들고 되돌려주는가?

[chang12]

클라이언트가 페이스북 로그인을 통해 어떤 데이터를 얻는가?

액세스 토큰 웹 페이지
만료 및 연장 웹 페이지 - 유저/클라이언트/서버 사이의 다양한 시나리오를 확인할 수 있다.

• 앱에서 Facebook API에 대한 임시 보안 액세스를 제공하는 액세스 토큰을 얻음
• 토큰에는 만료 시기와 토큰을 생성한 앱에 대한 정보가 있음
• 액세스 토큰마다 여러 다른 사용 사례를 지원하고, 우리가 사용할것은 사용자 액세스 토큰
• 사용자 액세스 토큰은 단기 실행 토큰과 장기 실행 토큰의 두 양식으로 제공됨
• 일반적으로 단기 실행 토큰의 사용 시간은 약 1~2시간, 장기 실행 토큰의 사용 시간은 약 60일
• iOS 및 Android SDK를 사용하는 모바일 앱은 기본적으로 장기 실행 토큰을 가져옴
• 앱 사용자가 Facebook 서버에 요청을 보내면 해당 토큰이 하루에 한 번 갱신
• 요청이 없다면 토큰이 약 60일 후에 만료
• 만료되었다면, 사용자는 새 토큰을 얻기 위해 다시 로그인 플로를 거쳐야 함

결론 = 로그인 플로를 통해 사용자 액세스 토큰을 획득한다.

[chang12]

클라이언트가 서버에게 어떤 데이터를 보내는가?

앱이 실행되는 플로우를 생각해봐야 할 것이다.

스플래시 엑티비티가 실행될 때

• 모바일 디바이스에 저장된 token 값이 있다면 서버에 이를 보내서 검증을 거친다.
• 모바일 디바이스에 token 값이 없다면 Facebook 로그인 플로우를 거쳐 access_token 값을 얻어 이를 서버에 보낸다.

그 이후

• 서버로부터 얻은 token 값을 요청 헤더에 넣어서 authentication 한다.

[chang12]

서버는 어떤 데이터를 만들고 되돌려주는가?

스플래시 엑티비티가 실행될 때 - token을 보내는 경우

• 클라이언트가 보낸 token 값이 DB에 존재한다면 유저의 상세정보를 반환한다.
• 존재하지 않는다면 에러를 반환한다.
• UserDetail CBV에서 처리하면 될 듯 합니다.

스플래시 엑티비티가 실행될 때 - access_token을 보내는 경우

Graph API에 요청을 보내 이를 검증한다.

• 유효한 Graph API라면 응답에서 id 값을 찾아서 DB에 존재하는지 확인한다. 존재한다면, Token 인스턴스를 새로 만들어서 존재하는 User에 관계를 걸고, token 값을 반환한다.
• 유효한 Graph API였고, id 값이 DB에 존재하지 않는다면 새로운 User를 생성하고, 그에 관계될 Token을 생성하고, token 값을 반환한다.
• 유효하지 않다면 에러를 반환한다.
• UserCreate CBV에서 처리하면 될 듯 합니다. 내부에서는 정엽님이 만들어두신 fbGraphApi 메소드를 활용할 수 있겠네요. DRF의 APIView를 사용하기에 넘 힘들어서, 간단히 FBV로 개발했습니다. 개발하면서 추후 다른 SNS를 통한 회원가입이 이뤄질 것을 대비하여 손쉽게 로직을 덧붙일 수 있도록 신경썼습니다.

[chang12]

로직은 정리되었으니, 한눈에 파악할 수 있게 그림으로 정리해볼 필요가 있겠군요.

[chang12]

• 유저에 대한 Create, Retrieve, Update 연산을 하나의 CBV와 하나의 Serializer로 처리하려고 했지만 실패.
• Create는 access_token을, 나머지 두개는 fb_id 등의 유저 정보를 입력으로 받아야 하는데 이 분기된 로직을 하나의 Serializer를 통해 구현하는것이 불가능하다는 것을 알게됨.
• 자세한 이유는, DRF의 Request 객체의 data property의 setter가 정의되어있지 않으므로, request.data를 수정할 수가 없기 때문.

[chang12]

유저/토큰의 Create 로직에 리팩토링 요구되는 부분

• TokenSerializer에서 UserSerializer를 거치지 않고 MyUser Manager를 통해 바로 User 생성