8일 동안 블로그에 글을 못썼다.
글을 못쓴 이유는 8일 동안 뭔가 진전되었다고 할 만한 결과물이 안나왔기 때문이다.
8일 동안 삽질만 계속했다...
지금 공부하고 있는건 Node JS 를 이용한 로그인 구현인데,
인터넷 자료들을 이용해서 공부하려고 보니 다들 node js 로 프론트와 백을 모두 커버하고 있다.
그래서 그 자료들을 곧이 곧대로 내가 공부하면서 만들고 있는 클론 코딩 프로젝트에 대입을 할 수 가 없다.
(그 자료들 만으로도 충분히 할 수 있는데 내가 못 하는 걸지도 모르겠지만 ㅋㅋㅋ)
프론트 로그인 페이지에서 입력된 아이디 비밀번호를 백엔드 서버로 전송하고
백엔드 서버에서 받은 요청을 DB 정보와 비교해서 일치하면 응답으로 세션 생성과 함께 메인페이지로 리다이렉트를 시키고자 했다.
사실 세선 생성전에 리다이렉트부터 구현하려고 했는데, res.redirect() 가 cors 에 막혀서 여기에서 1차 멘붕
구글링을 이틀 동안 하루종일 했는데, 그냥 데이터 전송은 됐으나 리다이렉트만큼은 끝끝내 해결을 못했다.
내가 하고 있는 클론 코딩 프로젝트 주소가 http://www.everdu.ga/project/ym_music 인데
로그인페이지 http://everdu.ga/project/ym_music/login 에서 로그인 정보를 백엔드인
http://api.everdu.ga/project/ym_music/login 으로 보내는 건 성공했다.
이제 api.everdu.ga 는 NodeJS 앱에서 라우팅을 처리하도록 했는데, /login 요청에 대해
res.redirect(http://everdu.ga/project/ym_music); 을 해서 클라이언트로 하여금 메인페이지로 리다이렉트 하도록 했다.
개발자 도구에서 네트워크 탭을 보니까 리다이렉트 응답 받는거까지는 OK
근데 문제는 이 리다이렉트를 수행하는 과정에서 일어났다.
http://everdu.ga/project/ym_music/ 에서 보내온 응답에 Access-Control-Allow-Origin 헤더가 없다는 것이다.
실제로 주고받은 헤더를 보니까 응답 헤더에 위 해더가 없었다.
생각을 해보니 당연했던게 프론트는 백엔드로 데이터를 요청하는 입장이지, 반대로 프론트가 백엔드로부터 무언가 요청받을 일이 없었으니 설정을 당연히 안해놨다.
근데 이걸 쓰고 보니까 궁금해진건데 브라우저도 저 프론트 서버로 결국은 뭔가 요청을 보낸 건데, 네트워크 탭을 가보면 응답헤더만 있고 요청헤더가 없는 경우가 있다. 메인 html 에서 css 나 javascript 연결된건 요청이 있는데, 이건 내가 직접 링크 친게 아니니까 html 에서 같이 요청했다고 생각하면 요청헤더가 있는게 당연하다.
브라우저 주소창에 입력해서 접속한 사이트는 요청헤더를 원래 안보여주는 걸까..
브라우저가 처음 요청할 때는 CORS가 안뜨는 건가. 브라우저가 처음 요청할 때 브라우저의 Origin 은 뭘까 컴퓨터의 ip 주소인가..
암튼 그래서 프론트에서 Access-Control-Allow-Origin 을 허용해주려고 생각을 해보니까 프론트의 서버? 역할은
웹서버인 nginx 가 해주고 있으니 nginx 에서 저 헤더 설정을 해주었다.
그리고 다시 해보니까 여전히 안된다.
그래서 네트워크 탭에서 헤더를 보니까 안들어가있다 으아아악!!!!
그냥 주소창에 쳐서 들어가서 보니까 이때는 또 들어가 있다 으아아아악!!! 왜 리다이렉트만 안되냐고!!
nginx 설정 들어가기 전에 보니까 preflight 부터 막히길래 검색해서 OPTION 메소드에 대해 헤더 설정을 해주니까
preflight 요청에 대해서는 더이상 오류가 안났는데 본 요청에서 에러가 난다....
그래서 그냥 백엔드 서버에서 fetch 로 클라이언트 서버의 데이터를 백엔드로 가져와봤는데, 이건 또 잘 된다.
보니까 redirect 만 (301 status 코드만 있으면) 그냥 막는다...
그래서 결국엔 그냥 잘 되던 일반 문자열로 대충 로그인 성공했음~ 하는 문자열 보내주고
클라이언트에서 로그인 성공했다고 문자열을 받으면 location.href 로 직접 설정 바꿔서 메인페이지로 이동하도록 코딩했다.
그리고 또 찾아보니까 이 '리다이렉트' 의 과정이 B가 A 에게 C로 리다이렉트하라고 응답을 보내면
1. A 가 B에게 요청
2. B 가 A에게 C 로 가라고 응답
3. A 가 C 로 다시 요청
이런 과정으로 리다이렉트가 된다고 되어있는데, 이게 맞으면 대체 왜 CORS가 뜨는지 모르겠다
1. everdu.ga/login 이 api.everdu.ga/login 으로 인증 요청
2. api.everdu.ga/login 이 everdu.ga/login 에게 로그인에 성공했으니 everdu.ga/ 로 가라고 응답
3. everdu.ga/login 이 everdu.ga/ 로 다시 요청 (오리진이 같으니 CORS가 뜨면 안됨)
이 순서가 되어야 한다고 이해했는데, 네트워크탭에서 확인해보면
1번하고 2번은 잘 됐다.
문제는 3번에서 막힌건데, 3번에서 CORS로 막힌거 내용을 읽어보면 api.everdu.ga/login 으로부터의 everdu.ga/ 로의 redirect 요청에 대한 응답 헤더에 CORS 예외 헤더가 없어서 정책 위반이라고 안된다는 거다.
B가 A에게 리다이렉트 응답도 돌려주면서 동시에 C로 요청까지 보내는건가...?
사실 여기서부터 그냥 어거지로 겉으로 작동하는듯 보이게만 코딩한 느낌이라 좀 불편한 마음이 있었다.
그 다음에 로그인한걸 유지하려고 세션을 쓰기 위해 검색을 통해 세션을 적용시켰다.
그랬더니 이번엔 세션이 리다이렉트 되기 전 everdu.ga/login 페이지 에서까진 유지되는거 같은데, location.href로 이동한 다음부터는 세션이 클라이언트에 없다. (세션값을 저장한 쿠키가 없다)
분명 한번 session 생성하고 set-cookie 헤더로 쿠키 설정되면 그 이후부터는 서버로 요청할 때마다 알아서 쿠키와 함께 요청을 보낸다는데, 아무린 쿠키가 없다고 뜬다.
여기에서도 막히니까 결국 현타가 와서 일단 때려쳤다.
이 부분을 해결해보려고 인터넷에 검색을 했더니 앞에서 말한 것처럼 내가 본 게시글은 전부다 프론트와 백이 노드앱 하나에서 작동하는 상황에서 작성된 게시글이었다. (물론 적용해봤는데도 해결 안됨..ㅎ)
내가 이 클론 코딩 프로젝트를 분리해서 만들고 싶은 이유는 최대한 실무같은 환경에서 공부를 하고 싶었기 때문이다.
실무에서는 프론트와 백엔드 개발자가 나뉘어서 협업을 할 텐데, 한 폴더에 프론트와 백이 모두 한 폴더에 들어있는 구조의 앱이라면 두 개발자가 같은 레포지토리에 들어있는 서로 다른 파일에 대해 작업을 한다는 말인데,
과연 실제로 이렇게 작업을 하기도 하는지는 잘 모르겠다.
그리고 서비스의 규모가 커지게 되면 개발자 수도 많아질텐데 이러면 아무리 생각을 해봐도 하나의 프로젝트 구조에서 각자 부분을 나눠서 개발한다는건 상상이 잘 안된다.
Firebase 와 플러터로 군대오기전에 했던 플러터 개인프로젝트도 백과 프론트가 완전히 분리 되어있었고
지금 군대 사무실에서 유지보수하고 있는 프로그램도 백과 프론트가 완전히 분리되어 있다.
둘다 윈도우앱, 모바일 앱이라는 차이점이 있기는 하지만, 그래도 분리해서 하는게 좀 더 실무에 가까울 것 같다고 생각했다.
그래서 지금까지 분리해서 작업해왔고 계속 분리하고 싶었는데...
이걸 인터넷에 무료로 공개된 자료만 갖고 공부하려니까 쉽지가 않다.
그래서 그냥 지금 프로젝트는 잠깐 이대로 놔두고 다른 유명한 프로젝트로 (Todo 앱 같은거) 바꿔서
그냥 한 앱에서 작동하는 프로젝트부터 하면서 먼저 공부해볼까 생각하고 있다.
그리고 만약에 내가 성공적으로 분리해서 작업하는걸 성공하게되면, 누군가는 나같은 삽질 안하게
프론트와 백이 분리된 상태에서 Node 로 백엔드 로그인 구현하는걸 포스팅해볼거다...
근데 진짜 이 고민 내가 처음한거 아닐거 같은데 뭔가 검색하면 나올거 같은데 내가 못찾는건가..?
'자기계발 > 생각 정리' 카테고리의 다른 글
개발자로의 취업과 성장에 대해 - NHN 자회사 CEO 동문 초청 강연 후기 (0) | 2023.11.23 |
---|---|
2023년 10월 회고 (4) | 2023.10.31 |
군대 & 2022년 회고 (7) | 2022.12.30 |
오라클 클라우드, nginx, proxy_pass, err_address_unreachable (0) | 2022.05.18 |
내 도메인이 날아갔다... (2) | 2022.04.05 |