728x90

세션 풀림 문제 중 가장 중요한 것 하나는 Android Side - Back-end Side - Godomall 로 이어지는 연계순서였다.

중간에 이 과정에서 Spring 에서 "Bearer " 에 대한 String 을 떼어버리고 파싱한 뒤에 Godomall 쪽에 이어지는 순서로 접근하게 되는데, 이 과정에서 다시 한 번 Session Connection 이 이루어질 수 있었다.

 

자 그러면 본론으로 돌아가서 왜 한번의 Session 발급 이후에 Session 이 풀리고나서 로그인하기 힘들었던 이유가 있었는지 생각해보자

 

 

1. 

Moyamo Android Side run - init - Shop request 

이 순서상에서 이루어질 때, 앱을 처음 실행한 사용자라던가 캐시가 없는 사용자라면 해당하는 부분에 대해서 다시금 Session Sync 가 이루어졌어야 하기 때문에 한번의 연결은 정상적으로 작동하게 된다.

 

다만 그 이후에 refresh Token 이라던지 access Token 이 들어왔을 때에 주기적으로 돌아야 하는게 없었기 때문이다.

- 물론 이 부분에 대해서 찾아보면 refresh Token 이나 access Token 에 대한 로직이 있을지라도 활성 사용자수인 25만명에비하여 실사용자는 5~7만명에 그칠 것이기에 데이터베이스에서 직접 긁어다가 작동시키는 부분은 생각보다 비효율적인 트래픽을 야기할 수 있다.

 

2.

그렇다면 어차피 끊긴 김에 User의 Shop Profile 을 확인하는 End-Point 를 호출해서 소환하는 구조로 간다.

- 이 경우 Android 사이드에서 앱이 켜질때마다 request 를 날려주는 번거로움이 있긴 하지만 적어도 Session 에 대한 안정성은 보장할 수 있다. 따라서 Web-View 상에서 불러오는 쿠키의 Session 에 대해서도 변함없이 사용자가 서비스를 지속적으로 이용하게 해줄 수 있다.

 

따라서 이번엔 2번으로 접근하는 것을 유도해보고, 1번은 별도의 분석에 들어가기로 했다.

+ Recent posts