<WIL>한 주 간의 회고 그리고 실전 프로젝트 시작

박건영(Parkgunyoung)·2022년 6월 26일
0

WIL

목록 보기
7/8
post-thumbnail

클론코딩 주차가 끝나고 실전 프로젝트 주차가 시작되었다.

벌써 항해99를 시작한지 반이 지났고 이제 남은 것은 실전프로젝트 이다.

미니프로젝트 주차와 클론코딩 프로젝트 주차에서 우연치 않게 2번 연속 로그인 쪽 기능을 담당하게 되었고 프론트 앤드와 협업을 진행하면서 수많은 트러블슈팅을 하게 되었던 것 같다.

마냥 어렵게만 느껴졌던 로그인 기능 구현이 이제는 어느정도 감이 잡히기 시작했다는 것에 만족을 느끼고 있다.

지난 2주를 다시 돌아보면 미니프로젝트 기간에는 스프링 시큐리티를 이용하여 세션방식의 로그인 기능을 구현하였었다.

리액트 팀원분들과 협업을 하였기에 기존 숙련주차에 사용하였던 폼로그인 방식을 사용하지 않았고 따로 필터를 만들어 세션로그인을 구현하였었다.

https://github.com/0AndWild/recipes (미니프로젝트-깃헙)

미니프로젝트 주차에서 가장 속을 썩였던 부분은 당연 CORS 정책이였고 이는 지난 WIL에 정리를 해두었기 때문에 링크를 첨부하겠다.

https://velog.io/@0andwild/첫-협업을-진행하며미니프로젝트WIL.220619

다음으로는 로그인한 유저의 세션을 담은 쿠키를 브라우저에 저장을 하여 이 유저가 인증을 받은 유저라는 것을 확인 시켜주는데 프론트와 협업을 하다보니 서버에 배포를 하여 연결을 하고나서 문제가 발생하였다.

바로 samesite 문제였다.

브라우저 정책이 변경됨에 따라 cross-site에서는 samesite를 None으로 설정해주어야 했고 samesite를 none으로 설정하기 위해선 secure을 true로 해주어야 하는데 secure이 true일 경우 https를 사용해야했다.

이와 같은 samesite 설정을 하지 않을 경우 로컬 테스트에서는 문제가 없었지만 서버에 배포를 한 후에는 samesite 문제로 인해 로그인한 유저가 브라우저에 쿠키정보를 저장할 수 없었다.


클론코딩주차(AirBnB)

지난 주차였던 클론코딩 주차에서 우리조는 AirBnB를 클론 해보기로 하였고 짧은 시간안에 전체 사이트를 클론을 할 수 없었기에 나라를 한국에 한정지었고 스코프를 로그인, 숙소등록, 상세페이지의 댓글 CRUD로 잡았다.

https://github.com/AirBn-Clone-BE (AirBnB클론-깃헙)

이번 로그인 기능을 구현할 때는 미니프로젝트 때와 달리 JWT 를 이용한 로그인 기능을 구현해보았고 Spring security를 함께 사용하였다.

트러블슈팅

1) 댓글조회

  1. jwt와 스프링 시큐리티를 함께 이용하여 시큐리티에서 요청 설정 부분에 댓글 작성 API (/api/comment/{houseId})를 User권한을 가진(로그인한사용자)만 가능하게 설정을 해두었었는데, 댓글작성과 댓글 조회 api가 동일하여 배포후 테스트에서 댓글 조회가 로그인한 유저만 보이는 에러를 발견하였고, API 명세를 수정하여 댓글 조회 API를 /api/allcomment/{houseId} 로 변경하여 User권한 설정에 포함되지 않게 만들어 해결하였음.

2) 중복로그인 방지

  1. 중복 로그인을 방지하기 위한 로직을 만들어보기 위해 로그인시 db에 저장된 로그인한 사용자의 refreshToken값을 기준으로 로그인 상태를 판별하여 있으면 이미로그인한 상태, 없으면 로그인 성공으로 처리가 되게 하였으나, 기존에 로그인 할 때 생성된 refreshToken 삭제가 따로 되지 않고 계속해서 쌓이고 있어 이를 해결하기 위해 logout postmapping을 만들어 로그아웃시 해당 유저의 refreshToken을 삭제하게 만들어 해결하였음.

아쉬운점은 refresh 토큰을 이용하여 로그인중복 방지를 거의 마지막에 추가적으로 남은시간에 구현을 하다보니 postman을 이용하여 test를 다 하고도 시간상 프론트와 연결을 해보지 못했다는 것이였다.

또한 구현을 다 하고 나서 든 생각은 이 방식이 좋지 않은 방식이라는 점이였다.

refresh토큰을 MYSQL db에 저장 하다보니 로그아웃 시 따로 삭제를 해주어야 로그인 시 db에 저장된 refreshtoken이 있는지에 따라 중복로그인을 막는 기능이 정상적으로 작동이 되었다는 점이였고, 만약 redis를 사용할 줄 알았다면 따로 refreshToken을 삭제하는 mapping을 만들지 않아도 되었을 것 같다는 생각이 들었다.

그리고 마지막으로 이렇게 구현을 하였을 경우 만약 한 유저가 A라는 컴퓨터에서 로그인을 하고 로그아웃을 하지 않았을 경우 B라는 컴퓨터에서 다시 로그인을 할 수 없다는 것이였다. 즉, 같은 유저가 다른 컴퓨터에서 동일한 아이디로 로그인을 할 경우 이전 컴퓨터의 로그인 상태는 종료를 시켜주고 새로운 컴퓨터의 로그인 정보를 인가해주어 새로 갱신시켜주어야 하는데 이러한 측면까지 생각을 하지 못했던 것 같다.

만약 다음번에 로그인 기능을 구현하는 일이 생긴다면 이러한 측면을 고려하여 다시 중복로그인 방지를 구현해보고 싶다!


글을 마치며

이번 실전프로젝트에서 마음이 맞는 프론트앤드 팀원분을 구하여 리더, 부리더로 신청을 하였다. 나는 부리더로서 다른 리더 부리더 분들과는 다르게 실력은 터무늬 없이 부족하지만 열심히 노력하여 팀을 이끌어나가고 싶고 팀분위기가 다운되지 않게 만들어 끝까지 팀원들을 프로젝트 완성까지 이끌어나가보려 한다.

프로그래밍 공부를 시작한지 두 달도 채 되지 않았고 많은 팀프로젝틀를 겪은 것은 아니지만 이전 사회생활을 하면서 느낀점과 항해99에 들어와 진행하였던 팀 프로젝트를 진행하면서 느낀점은 팀이 구성되어지고 만드는 첫 시작 분위기와 팀원들과의 지속적인 소통이 일처리의 효율과 속도를 올리는데 있어 정말 중요하다는 것을 다시 한 번 느끼게 되었다.

이를 바탕으로

  1. 팀원들과의 지속적인 소통

  2. 항상 긍정적으로 생각하기(부정적으로 생각을 하면 끝까지 부정적인 사고에서 벗어날 수 없는 것 같다.[주관적인생각])

  3. 문제점을 함께 해결해나가려고 하기(첫 항해를 시작하고 프로그래밍을 하면서 발생하는 에러들을 혼자서만 해결하려다보니 해결에만 초점을 맞추고 그 이외의 다양한 방식을 생각하지 않게 되었던 것 같다. 팀원들과 함께 고민해보고 문제를 해결하다보면 더 많은 관점들을 바라볼 수 있게 되고 시야가 넓어지는 것을 느꼈다.)

등 을 지켜나가면서 이번 실전프로젝트를 성공적으로 끝마치고 싶다! ㅎㅎ

profile
쓰러지면어때일어나면그만인걸

0개의 댓글