본문 바로가기
bookmarked/먹고사는 문제

next-auth credentials 에러와 마주하기 (feat. Django)

by 고니-gonnie 2023. 8. 27.
반응형

TL; DR

api 를 장고서버로 구축했다면, api 호출하고 제일 뒤에 항상 / 를 꼭 붙여주자. 안그러면 뒤통수 맞는다.

개요

부업을 하고 있다. 로그인을 구현해야하는데 next.js 를 사용하고 있으면 next-auth 만큼 쉽고 편한 것도 없다. 일단 서버측 호출이기 때문에 cors 에서도 자유롭고, 무엇보다 우리가 흔히 생각하는 로그인 했을 때, 안했을 때를 쉽게 구분해주고, 무엇보다 역시나 서버측이다 보니 oauth-id 나 secet 같은 것을 편하게(?) 가져다 쓸 수 있다. 보통 하는 브라우저측 호출로 진행한다면 절대 해서도 안되고 할 수도 없는 방법이다.

그런데 오늘 부업을 진행하는데 자꾸 로그인이 안된다. postman 에서 호출하면 잘만 되는데 개발환경에서 next-auth 의 credentialsProvider 를 사용하면 자꾸 에러라고만 나온다.

문제

next-auth 를 사용하는 순간, 로그인과 같은 과정을 서버측에서 처리하기 때문에 브라우저 개발자 도구의 네트워크 환경에서 볼 수 있는 것이 하나도 없다. 즉, 이게 요청이 잘 갔는지, 혹은 잘못되서 뭔가 이상하게 되돌아 온건지 확인할 길이 없어진다. 물론 터미널에서 볼 수는 있지만 브라우저의 그것과 차원이 다르고 잘 안찍히는 경우도 많다.

 

오늘의 사건은 위에 먼저 써놨듯이 장고로 만들어진 api 의 엔드포인트 끝에 슬래시를 추가하지 않았기 때문이다. 이걸 알게된 방법은 로그인 api 를 일부러 브라우저에서 강제로 호출해보고 브라우저 개발자 도구의 응답을 보았는데 거기에 너무나 자세하게 api 엔드포인트 제일 뒤에 슬래시를 붙이라고 써 있는 메시지를 보게된 것이다.

 

보통 이런 에러메시지는 html 로 내려오다보니 next-auth 같이 메시지 위주로 전달해주고, 심지어 에러페이지로 리다이렉트 해버리는 상황이라면 이게 도무지 무슨 일이 벌어지고 있는건지 알 방법이 없어진다.

결론

솔직히 요즘 코딩실력도 떨어지고 예전같지 않아서 이 문제때문에 참 자괴감이 많이 들었는데 결국은 api 서버를 구성한 프레임워크의 특징이었다. 

반응형