부트캠프 개발일기123 91일차: Pre-Project Day 11 (Mapper/MapStruct 생성안됨) 코드를 실행하면서 가장 문제가 되었던 부분 중 하나가 Mapper였다. 분명히 메서드 파라미터 타입, 리턴 타입 모두 잘 작성되어있고 의존라이브러리도 추가되어있고, 애너테이션도 잘 붙어있고 인터페이스 타입으로 생성되어있고 Entity, Dto 필드명도 일치하는데 뭐가 문제일까 한참을 고민했다. 심지어 또 어떨때는 생성이 되기도하고 어떨땐 안되기도 해서 정말 뭐지? 라는 고민을 많이했다. (그래서 초반에는 일단 코드를 돌려야겠다는 생각에 디폴트 매퍼를 생성해서 사용하기도 했다.) 이제 코드가 어느정도 정리되고나니 여유가 생겨서 해당 부분 문제를 해결해보기로 했다. 구글링해보니 이유가 명확히 있었다. 사용중인 Lombok과 MapStruct간에 충돌이 나서 그렇다고 한다. Getter, Setter를 사용해.. 2023. 6. 23. 90일차: Pre-Project Day 10-2 (코드 Merge, CORS 오류 해결, Ngrok) 백엔드 팀원들의 코드를 모두 합친 첫날이었다. 아무래도 각자 다른 부분을 작성하고 연관관계도 있다보니 처음에는 컴파일 오류나는 부분들이 꽤 있었다. 그래도 import 설정을 추가하고 일부 수정했더니 다행히 코드가 잘 실행됐다. github에 코드 올리고 머지하는것도 이제는 조금 익숙해져서 비교적 큰 충돌 없이 잘 진행되고 있다. 아무래도 부트캠프 과정에서 배운 내용을 바탕으로 하고있고 초기에 API명세, 테이블명세를 잘 작성해두어서 필드명이나 메서드명을 서로 참조하는게 편했던것같다. 다음에 본 프로젝트에 들어가서도 코드 구현 전에 분석, 설계 부분을 명확히 하는게 중요할것같다. 그런데 한가지 문제가 생겼다. 아직 배포환경은 구성하지 못해서 Ngrok을 통해서 프론트엔드 코드와 연동 테스트를 하려고했는데.. 2023. 6. 23. 90일차: Pre-Project Day 10-1 (인증 에러 처리: AuthenticationFailureHandler, AuthenticationEntryPoint) 로그인, 로그인 상태 검증 등 인증과 관련된 내용을 정리하다보니 인증에 실패했을때 리턴 형태에 대해 고민하게 되었다. 지금은 기본 지정된 상태로 값이 리턴되고 있다. 이걸 에러코드 / 메세지로 깔끔하게 보내는건 어떨까? 하는 생각이 들었다. 인증과 관련해서 발생할 수 있는 에러는 크게 두가지로 나뉜다. 먼저 로그인(Authentication)과정에서 실패하는 경우 -> AuthenticationFailureHandler를 통해 원하는 작업을 지정할 수 있다. 그 외 인증 과정에서 만료된 토큰이나 조작된 토큰 등 유효하지 않은 인증 정보를 사용하는 경우 -> 발생한 에러를 AuthenticationEntryPoint에서 잡아서 처리할 수 있다. 먼저 로그인에 실패했을때 에러 코드 / 메세지를 출력할 수 있.. 2023. 6. 22. 89일차: Pre-Project Day 9 (HandlerInterceptor, JWT 정보 가져오기) 이제 회원가입/로그인/로그아웃 관련 기능들을 어느정도 마무리하고 무엇을 해야할까 고민하던중 "코드가 merge되지 않은 상태인데 다른 팀원분들은 질문/답변 등록할때 memberId 같은 정보를 어디서 받아올 수 있을까?"라는 의문이 생겼다. 질문/답변 조회의 경우 별도의 사용자 인증이 필요 없는 상태이지만 등록이나 수정할때는 인증된 사용자만 가능하다. 그렇다면 클라이언트가 질문이나 답변을 POST, PATCH 할 때 내용 뿐만 아니라 memberId와 같은 정보도 계속 보내야하는가? 하는 생각이 들었다. 현재 JWT를 통해 인증 여부를 확인하고 있으므로 JWT에서 회원 정보 관련 내용을 추출할 수 있다면 클라이언트측에서 추가로 회원 정보를 보낼 필요가 없다. 그렇다면 JWT에서 어떻게 회원 정보를 가져올.. 2023. 6. 21. 88일차: Pre-Project Day 8-2 (JWT 로그아웃, Redis) 이번 프로젝트를 진행하면서 가장 복잡했던 부분이다. 부트캠프 과정에서 배우지 않았던 내용이라 검색을 통해 여러 자료를 참고했다. 아직 학습 중인 단계라서 정확하지 않은 부분이 있을 수 있다. (혹시 잘못된 부분이나 더 나은 방법이 있다면 편하게 말씀 부탁드립니다.^^) 우선 JWT는 세션방식과 달리 서버 측에 해당 정보가 저장되지 않는다. 따라서 서버에서 임의로 JWT를 삭제할 수는 없다. 그렇다면 어떻게 로그아웃을 구현할 수 있을까? -> 해당 토큰이 유효하지 않은 토큰이 되면 된다. 현재 리프레시 토큰을 사용해 액세스 토큰을 다시 발급받는 과정은 구현하지 않은 상태이다. 따라서 액세스 토큰을 무효화 하는것만 우선적으로 구현했다. (리프레시 토큰을 사용할 경우 해당 토큰도 무효화해야 한다.) 그렇다면 .. 2023. 6. 20. 88일차: Pre-Project Day 8-1 (JWT 검증) 오늘은 크게 두가지 작업을 진행했다. 내용이 길어서 두개 포스팅으로 나누어서 작성한다. 먼저 로그인 완료한 사용자가 발급받은 JWT를 헤더에 넣어 요청을 보내면 적절한 JWT인지 검증하는 로직을 구현했다. JWT를 검증하는 전용 Security Filter 를 구현해서 Filter Chain에 적용하는 방식으로 진행하였다. 이번에도 나중에 팀원들과 얘기할것을 대비해서 주석으로 관련 내용을 기입해두었다. 프로젝트 기간이 짧다보니 PR 검토하는 시간이 부족하고, 각자 코드 작성하기에도 바빠서 설명이 필요해보이는 부분은 적어두었다. [JWT 검증] 1. JwtVerificationFilter: 실질적으로 JWT를 검증하는 역할을 한다. doFilterInternal() 메서드를 override하여 필요한 로직.. 2023. 6. 20. 이전 1 ··· 3 4 5 6 7 8 9 ··· 21 다음