소셜 로그인이 아닌 일반 로그인 기능을 구현하는데 있어서
리액트와 스프링 부트와의 협업으로 진행하였다 회원가입 절차는 api 명세서에 나와있는대로 진행하였다
api명세서에
이러한 기능들이 있어서 axios를 사용하여서 통신을 진행하였다.
다만 통신에서 문제가 있었다면
백엔드와 프론트엔드 사이에서의 로컬에서는 통신이 잘되었지만 배포된 주소로는 잘안되었다는 점이다.
이러한 이유는 크롬에서 https와 http간의 통신을 막아놨다는 이유이다.
만약 내가 로컬로 요청을 보내어 응답을 받기위해 백엔드 배포주소(http)로 요청을 보내면 응답이 제대로 오지만 프론트 엔드 배포주소를 https로 하고 백엔드주소로 보내면 응답이 오지않는다는 소리이다.
이건 https를 적용후 api 요청을 http로 보내면 발생하는 브라우저 보안 에러이다.
https는 http의 TCP/IP통신에 SSL를 한층 더 위에 얹은 것이다.
이것에 대한 해결방법을 강구하던 도중 API요청을 HTTP에서 HTTPS로 바꿔서 요청을 보내기인데 이건 말도안되는 소리라고 생각했다 배포주소가 있는데 거기서 바꿔서 요청을 보낸다한들 안되기때문이다.
또하나는 프론트엔드에서의 INDEX파일에 meta태그를 추가하는 방법인데
<meta
http-equiv="Content-Security-Policy"
content="upgrade-insecure-requests"
/>이러한 방식으로 해보고 요청을 보내보면 axios에서 통신하려는 url이 강제로 변형이되어버려 잘못된 주소로 요청이 가는것을 확인했다 이유는 좀 더 알아봐야한다...
그렇게 삽질을 계속 3일간 하던도중 백엔드에서 그냥 배포주소를 http에서 https로 바꾸는 것으로 결정을 했다.
그런데 이러한 과정에서도 도메인을 따로 사는 과정도있었고 복잡했다...
그 후 통신을 했는데 잘되었다. https -> https
처음엔 요청할때의 바디가 잘못이되었다하고 계속 코드를 수정하며 바꿔가면서 요청을 보냈다 무수히 많은 에러를 보던도중 계속해서 mixed content에러가 뜨길래 이것에 대해서 봐보니 처음부터 잘못되었다는 사실에 놀랐다..하하...
그래도 끝까지 할수있었던건 백엔드 개발자들의 꾸준한 노력이였다..그걸보면서 동기부여를 삼았다.
그덕에 놓지않고 계속해서 할수있었다. 또하나의 이유는 콘솔에 정확히 찍혔던 requestBody이다. 바디가 정확하게 보내진다는걸 보여주는 단하나의 희망줄이였다...