건의사항
이전의 OAuth2 로직 개발
백엔드에서 구현한 기존의 로그인 흐름은
로그인 페이지 → 소셜 로그인(OAuth2) → 메인 페이지로 redirect
이렇게 구현이 되어 있었습니다.
(즉 로그인 시 프론트엔드에게 Json으로 내려주는 데이터는 구상하지 않았었습니다.)
2022-07-29일 회의에서 회원가입하다 사용자가 나갈 경우를 대비해
- 프로필이 있는 경우 → 피드 페이지
- 프로필이 없는 경우 → 프로필 생성 페이지
로 사용자를 보내 주기로 했습니다.
이에 예상되는 로그인 흐름은
로그인 페이지 → 소셜 로그인(OAuth2) → 로그인 데이터 반환(Json 형태, userId, hasProfile? 등) → 프론트엔드에서 페이지 redirect
으로 예상이 되는데(잘 이해한 것 맞겠죠?)
이 때 로그인 데이터 반환(Json 형태로)에서 추가적으로 필요한 데이터를 적어 주시면 감사할 것 같습니다.
{ "hasProfile" : true }
답변
- 그루트:
- oauth 인증 중간에 나가는 경우
- oauth이후 redirect 로 추가 정보 묻는 페이지에서 나가는 경우(아래 페이지)
- 프로필이 있는 경우 → 피드 페이지
- 프로필이 없는 경우 → 프로필 생성 페이지
- 프론트엔드에서 사용자가 프로필을 생성한 경우, 생성안한 경우를 hasProfile로 받고 그에따라서 페이지로 이동시켜주는 것으로 이해했었습니다! 혹시 제가 다르게 이해한걸까요!?
사용자가 회원가입하다가 나가는 경우가 두가지 있을 것 같습니다.

1번의 경우 아무것도 저장되지 않은 경우
2번의 경우가 db에 프로필이 생성된 경우라고 이해했습니다.
하니와 그루트의 대화
맞나요?? 잠시만요!
일단 OAuth2 중간에 나가는 경우는 User가 생성 조차 안되어서
그쵸 그때는 다시 들어오면 그냥 회원가입페이지로 가야겠죠? 넵!
그 후 프로필 생성 페이지, 등등으로
가는거죠!?
이 때 사용자가 나가는 상황을 고려해야하는거죠!?
네네
ouath가 리다이렉트를 여기로 주는걸로 이해했습니다
여기서 더 추가정보를 입력하고 회원가입이 끝나는걸로.
저는 이렇게 이해했는데요!
구글 로그인을 하면 이제 위처럼
생성안한경우가 뭐죠?? 중간에 나가서 없는건가요??
넵 중간에 나가서 프로필이 생성안된경우 입니다!
그러면 저 페이지로 가면 되지않을까요?

사용자가 저 페이지에 바로요!?
어 혹시 2인실 가서 같이 얘기할까요!?
넵!
네
- 그루트 추가 질문
Q. 그루트
아까 하니가 설명한거로 user와 profile이 1:1로 매칭되었다고 한거 같은데 user만있고, profile이 없는 경우는 바로 삭제가 되야하는거 아닌가요??
A. 하니
백엔드 테이블 상에서 user와 profile 이 1:1 관계를 가지고 있습니다! 이렇게 테이블을 두개로 나눈 이유는 user(OAuth2 로그인 중 생성)과 profile(선호 카테고리, 닉네임 등 입력)의 생성 주기?가 다르기 떄문인데요! 제가 1:1로 매칭된다고 말씀드린 이유는 아마도 한 명의 user가 여러 profile을 가지지 못하기 때문에 1:1로 매칭된다고 설명 드린것 같아요!
위에서 말씀해주신 user만 있고, profile이 없는 경우는 아래의 2번에 해당할 것 같네요! 다음과 같이 처리하면 좋을 것 같습니다!
- 아마 저희 어플리케이션 흐름 상 가능한 회원가입 flow는 다음과 같을 것 같습니다!
- 소설 로그인(create user) → profile(create profile)까지 생성 완료
- 소셜 로그인(create user) → profile 생성 중 탈주. 이 때 profile 데이터는 생성되지 않습니다.
- 소셜 로그인 후 hasProfile : true/false 데이터를 받는다
- hasProfile : true 인 경우 → 피드 페이지로
- hasProfile : false 인 경우 → 프로필 생성 페이지로
따라서 사용자가 다시 로그인할 때 프로필을 생성하지 않은 사용자들을 프로필 생성 페이지로 보내기 위해서
보내기로 얘기가 되었던 것 같습니다!
Q. 그루트
세션 좀 찾아보니 일회성 로그인에 사용된다는데 그럼 브라우저를 껐다키면 로그아웃이 되는건가요??
A. 하니
일단 제가 이해하고 있는 세션의 동작 방식에 대해서 설명 드리겠습니다!
- 사용자가 웹 페이지 URL 입력 후 서버에 요청한다.
- 서버에서 요청한 사용자가 최초로 요청했다고 판단되면 톰캣은 Response 헤더에 다음과 같이 JSESSIONID값이 발급된다. Set-Cookie: JSESSIONID=3CB361E0BE1A9A7DE7DB926DF0772BAE
- 전달된 JSESSIONID값은 쿠키 형태로 사용자의 매번 요청때마다 서버에 전달된다. 즉, 재요청시 Response를 통해 받은 jsessionid를 Request헤더의 쿠키에 값을 넣어 서버에 요청한다.
- 사용자에게 전달 받은 JSESSIONID값으로 동일한 사용자의 요청인지를 판단하여 사용자 정보를 유지한다.
서버에서는 OAuth2 로그인이 성공하면 해당 User에 대한 정보를(Session)에다가 담고 요청이 올 때마다 해당 세션에서 User 정보를 꺼내서 사용합니다!
여기서 중요한 점은 위에서 JSESSIONID 값을 쿠키에 담아서 Request를 날리죠!
브라우저가 꺼지면 쿠키가 사라지는것으로 알고 있습니다!(아마도요?)
그렇다면 브러우저를 껏다 키면 로그아웃이 됩니다.
becuase 쿠키 사라짐 → 세션 사라짐 → user 인증 정보 사라짐
+) 추가 TMI
백엔드에서는 세션ID와 세션 정보를을 DB나 Redis같은 데이터베이스를 사용해 보관할 예정입니다!
따라서 서버가 내려가도 세션 데이터(로그인)는 유지됩니다.
Q. 그루트
로그아웃하면 세션에 있는 값이 자동으로 지워지나요?? 아니면 저희가 뭔가 해줘야하나요 아니면 백에서 해주시는건가 궁금합니다.
A. 하니
넵! 로그아웃을 하면 세션 정보가 자동으로 지워지도록 코드가 작성되어 있습니다! 즉 백에서 처리됩니다!
제가 알고 있기로는 프론트엔드에서 따로 처리해 줄 사항은 없는것으로 알고 있어서 생기면 말씀드리도록 할게요!
설명이 부족하거나 이해가 잘 안되는 부분이 있으실때는 질문 남겨주세요!
- 효니:
- 그루트한테 그루트와 하니의 대화를 들은 결과 hasProfile값만 응답해주셔도 됩니다
- 🆗 - 하니