앞서 글의 내용으로 우리는 자동 로그인 기능은 씁쓸하지만 포기해야 하는 구나.. 를 얻었다.
그렇지만 더 설명해야 할 부분과 첫 번째 문제점을 해결하지 못한다고 타협하더라도 추가적인 문제가 더 있다.
문제점 2. 로그인 후 메인 페이지로 리다이렉트되는 현상.
어떻게든 귀찮음을 줄이고자 만든 자동화인데,
로그인 후에는 무조건 메인 페이지로 리다이렉트 되고 있다.
PC에서의 웹페이지는 이러한 기능이 잘 되는 것 같은데, 모바일에서만 발생하는 현상같다.
출석체크 페이지로는 리다이렉트 되지 않는다. 왜이럴까...?
굳이 이 페이지가 아니더라도 특정 페이지를 보던 중,
로그인이 필요한 상황이 되어서 로그인을 한 뒤 해당 페이지를 이어서 볼 수 없는 경험이 있을 것이다.
이는 우리에게 엄청난 귀찮음과 번거로움을 안겨준다.
이러한 현상은 왜 일어나는 것일까? 이번 글에서는 이를 파헤쳐 보겠다.
그리고 이를 알아내기 위해서는 API가 무엇인지에 대한 개념이 필요하다.
우선 지난 글에서 말했듯 API라는 개념에 대해서 일단은 웹 서비스에서 제공하는 하나의 소프트웨어라고 얘기했다.
하지만 API라는 개념은 웹에서만 국한되는 개념이 아니다. 이에 대해서 자세히 풀어보려고 한다.
API(Application Programming Interface)
Application; 우리가 정말 많이 사용하는 단어인 어플리케이션. 정확한 정의는 제품과 회사 별로 다르다.
그렇지만 그들이 말하고 있는 것의 키워드는 크게 3가지이다.
1. 사용자 중심 : 사용자가 어떤 작업을 수행하거나 문제를 해결할 수 있도록 설계된 프로그램
2. 상호작용 : 사용자 인터페이스를 통해 사용자가 직접 상호작용하는 기능이 제공됨.
3. 목적 지향 : 특정 목적 또는 문제를 해결하기 위한 도구로 설계
따라서 Application 을 "사용자가 어떤 목적을 갖고 사용할 수 있게 제공 되는 프로그램" 으로 생각 할 수 있겠다.
Interface : 인터페이스라는 단어는 어디서든 많이 등장하는데, 기본적인 개념은 두 구성 요소 간의 단면이나
두 구성 요소 간 상호 작용이나 통신이 일어날 때의 수단이나 부분을 일컫는다.
그렇지만 소프트웨어에서의 인터페이스란 사양(Specification)을 말한다.
우리가 어떤 컴퓨터를 구매할 때 스펙을 본다. CPU의 성능을 보고, RAM의 크기,,
그래픽카드는 어떤 것을 쓰고, 어떤 기능이 추가되었고, 이렇게 사용할 수 있는지 등 기능의 목록을 본다.
반면 이 컴퓨터가 어떻게 구동되는지 원리에 대해서는 전혀 신경을 쓰지 않아도 된다.
컴퓨터의 전원을 누르면 하드웨어에 전기를 공급하기 시작하고, 하드웨어 초기화와 진단을 수행하고,
부트로더를 실행해서 커널을 로드 후 실행하고 초기화 프로세스를 시작하고... 등
위와 관련된 작동의 원리를 신경쓰지 않는다. 사용자는 사용법만 알면 되는 것이다.
따라서 API를 종합하자면
어플리케이션을 프로그래밍하기 위한 사용자(프로그래머)를 위한 인터페이스
가 되겠다. 웹 API라는 것은 프로그래머가 어떤 기능을 사용하기 위해
웹 서비스 회사에서 제공하는 API가 되는 것이다.
문제점 2의 원인 분석.
그러면 앞서 글에서 잠깐 언급 되었던 네이버 로그인 API는 어떻게 사용하는 것인지 스펙을 살펴보도록 하자.
"네이버 로그인 API는 네이버 로그인 인증 요청 API, 접근 토큰 발급/갱신/삭제 요청API로 구성되어 있습니다. 네이버 로그인 인증 요청 API는 여러분의 웹 또는 앱에 네이버 로그인 화면을 띄우는 API입니다. 이용자가 네이버 회원 인증에 성공하면 API로부터 받은 code 값을 이용해서 접근 토큰 발급 요청 API를 호출합니다. 접근 토큰 발급 요청 API를 통해 받은 접근 토큰(access token) 값은 다음과 같이 회원 프로필 조회를 비롯하여 여러가지 로그인 오픈 API를 호출하는데 사용할 수 있습니다."
와 같이 설명되어 있다. 이는 이전에 썼던 글과 다른 부분이 있다. (우리가 생각해야 하는 API가 서버를 포함하면 3개다!)
다만 지금은 그것보다는 어떻게 사용되는지에 중점이 있기에 이 부분은 넘어가도록 하겠다.
현재 상황 분석.
네이버 로그인 팝업창이 뜨는 현재의 상황은
사용자(나)의 네이버 로그인 요청으로 서버측에서 네이버 로그인 인증을 위해 팝업창을 띄운것이고,
이때 팝업창의 URL이
`https://nid.naver.com/oauth2.0
/authorize?response_type=code&client_id=PV3hpxvmtFk1LHyP4GqI
&scope=login+userinfo
&state=0df613b7ac2547de0e72d192cd6ac3be1847049a868b3c616c0e20cdd85c0011c946b3f6a32d25481d649a36c05679a821b152490dce31a78afa74c9eb6fbbf2972e47a29ef215282d9be4cfa265e8e8e49894f62c3e6eedf73c4c0671514b78a0295fa5b45d31b9b6d2c1ebd63e36a5c12f71840d242d08656ac801ef8a8cf2
&redirect_uri=https%3A%2F%2F${domain}%2FApi%2FMember%2FOauth2ClientCallback%2Fnaver%2F`
이다.
위의 API 명세에 따르면 리다이렉트가 되는 페이지는 redirect_uri 라는 인증요청의 변수로 들어가게 된다.
그리고 이에 대한 값이
https%3A%2F%2F${domain}%2FApi%2FMember%2FOauth2ClientCallback%2Fnaver%2F 이다.
이는 서버측에서 입력한 Callback URL 값이다.
형태가 저렇게 되어 있는 것은 UTF-8로 인코딩 되어 있는 것이고,
이를 디코딩 한다면 https://${domain}/Api/Member/Oauth2ClientCallback/naver/의 형태가 나온다.
이 URL이 서버측에서 네이버 API에 등록한 리다이렉트 URL의 저장소이다!
문제점의 원인이 되는 핵심적인 부분을 API 명세를 통해 알아냈다.
하지만 이는 서버측의 URI에 저장이 되어있는 형태이기 때문에
사용자 입장에서는 어떻게 되어 있는 지 알 방법이 없다.
추측하건대, 서버측에서 설정한 URL의 값이 메인페이지가 될 가능성이 있다.
혹은 모바일의 경우에 로직이 제대로 설정되지 않아서 결국 메인페이지로 리다이렉트되는 가능성도 고려해볼만 하다.
그렇다면 내가 이 문제의 상황을 마주한 서버의 웹 개발자라 가정하고,
이러한 문제를 어떻게 해결하면 될까? 를 생각해보자.
보던 페이지에서 로그인을 했다고 다른 페이지로 이동하는 것은 사용자에게 불쾌함을 주기 때문이다.
해결책 1.
굳이 서버에 로직을 설정하지 않더라도 사용자의 웹브라우저를 활용하는 방법이 있다.
현재 사용자가 보고 있던 페이지(state)를 사용자 웹브라우저의 sessionStorage에 저장하게 하자.
서드파티 로그인 요청이 이뤄지기 전에 페이지와 현재 사용자의 상태를 state화 해서
이를 잠깐동안 sessionStorage에 저장하도록 로직을 설정하고,
로그인 요청이 끝나면 사용자에게 현재 state를 돌려주는 방식으로 하면 된다.
이 방식의 경우, 사용자의 디바이스가 모바일인 경우와 PC인 경우 두 가지에 대한 로직을 잘 나누는 것도 필요해 보인다.
세션에 저장하는 방식으로 수행한다면 더 나은 사용자 경험을 제공해 줄 것이다.
해결책 2.
sessionStorage를 사용해서 하는 방식 외에도 다른 방식이 있을까?
OAuth2.0의 state에서 이 state에 현재 사용자의 상태를 넣은 토큰을 제공하는 방식도 있지 않을까?
했는데 이 방식도 되긴 한다고 한다.
다만 URL의 길이에 따라 토큰 생성에 제한이 생기거나
CSRF(Cross-Site Request Forgery) 문제가 발생할 수도 있기에 제한된 선택지인듯 하다.
결론.
오늘도 역시 내가 해결할 수 있는 부분은 없었다.
다만 이번에는 내가 개발자라면? 의 입장에서 해결책을 찾아봤는데 이 방식도 재밌는 것 같다.
혹은 홈페이지로 리다이렉트 되도록 설정해놓은 이유가 다소 의도적일 수도 있다.
아무래도 출석체크를 하면 마일리지를 주는데 서비스 제공자 입장에서는
이 부분에서 조금이라도 더 귀찮아야 덜 손해를 볼테니 이런식으로 대충 만들 수도 있지 않았나 생각해본다.
'Trouble Shooting > episode 1. 네트워트 지연 에러' 카테고리의 다른 글
네트워크 접속 지연? (1) - REST API (0) | 2024.08.16 |
---|