회고장

👣 개요 JPA가 인식하는 데이터 타입은 다음과 같이 3분류로 나눌 수 있다. 1. 기본값 타입 - 자바 기본 타입(Ex. int, Integer, double) 2. 임베디드 타입 - 복합 값 타입 3. 컬렉션 값 타입 이 중 1번은 이미 알고 있는 내용이기에 2번, 3번에 대해서만 서술한다. 👣 임베디드 타입 임베디드 타입은 DB에는 반영되지 않지만, OOP에서 좀 더 OOP 스럽게 코드를 구성하기 위해 사용하는 도구다. 예를 들어, 집 주소를 표현하는 필드가 도, 시, 동이라는 3개의 필드가 있을 때, 응집성을 높이기 위해 3개의 필드를 위치라는 클래스에 담고 위치 클래스 타입의 필드 1개로 치환하는 것이다. 변경 전 코드 @Entity public class Member { @Id private ..

👣 개요 이번주는 주특기[Spring] 2주차로서 2인 1조로 페어를 맺어 Spring 관련 과제를 수행하는 주간이었다. 주제는 Spring Security와 Spring Data JPA를 이용해서 블로그 웹 사이트의 API 서버를 만드는 것이었다. 구체적으로 말하자면 회원 가입, 로그인과 같은 인증, 인가 API를 설계하는 것과 게시글을 단일 조회, 일괄 조회, 생성, 수정, 삭제를 수행하는 API를 설계하는 것이다. 이전의 프로젝트들에서는 Spring Security를 이용하기만 했지 Spring Security의 이론적 배경과 라이브러리의 코드들을 자세하게 살펴본적은 없었다. 하지만 이번 주차에 체계적으로 이론들을 다지고 인증, 인가에 관한 코드들을 천천히 뜯어봤다. 그에 대한 결과들은 다음과 같다..

👣 개요 오늘은 Lv 2에 대한 리뷰를 진행했다. 리뷰 간 직접 작성한 코드에 대해 상대 리뷰어에게 설명을 하니 오히려 코드에 대한 이해가 깊어지고 수정해야 하는 부분이 보였다. 로그인 API를 설계할 때, 로그인 성공 시 로그인 성공 메시지를 올려야 하는데 그 부분이 누락되기도 했다. 문제가 되었던 코드는 다음과 같다. 그래서 해당 코드를 다음과 같이 수정했다. 권장하는 방법은 아니지만 필터로 로그인을 구현하고 싶다면 이렇게 직접 HttpServletResponse 객체에 Body 내용을 print해야 한다.

👣 개요 오늘 오전엔 Lv 2 과제를 끝마치기 위해 팀원과 코드 병합을 진행하고 4시까지 API 명세서, 각종 문서화를 진행했다. 그리고 그 이후에는 부족한 Spring Security 관련 공부를 진행했다. 👣 Lv 2 코드 병합 Lv 2부터 본격적으로 팀을 이뤄서 과제를 수행하는 활동을 진행했다. 본격적인 항해 99과정을 진행하기 전에 웹 종합반에서 협업을 경험하긴 했으나 이번 협업도 너무 서툴렀다. 아무래도 기술 파악이 확실히 되지 않은 채로 계획을 짜니 빗나가는 것도 많고 놓치는 부분이 많았다. 아직 API 명세서와 DB 스키마 명세서를 구체적으로 적어야 하는 이유에 대해 공감할 수 있는 단계가 아니다보니 작업을 할당하는 것이 불가능했다. 작업을 잘게 쪼개기 위해선 위와 같은 규칙을 세심하게 정해..

👣 인증 필터의 업무 파악 우선 인증 필터가 수행해야 하는 업무를 나열하면 다음과 같다. 인증 전 AuthenticationToken을 만들기 해당 Authentication Token을 AuthenticationManager에게 위임해서 인증된 AuthenticationToken 만들기 SecurityContextHolder에 안착시키기 인증 오류 발생 시, 오류 처리하기 위 업무 중 3번과 4번을 미리 해결한 추상 클래스를 찾아보면 AbstractAuthenticationProcessingFilter 라는 클래스를 찾아볼 수 있다. 👣 AbstractAuthenticationProcessingFilter 분석 AbstractAuthenticationProcessingFilter는 3번을 해결하기 위해..

👣 개요 결국 UserDetailsService를 사용하고 싶지 않아도 UsernamePasswordAuthenticationToken을 사용한다면 어쩔 수 없이 UserDetailsService를 사용해야 한다는 것이다. 만약 JWT에 Username을 넣으면 안 된다거나 Id값을 Payload에 넣고 싶다면 [혹은 등등의 어떠한 이유로] UserDetailsService.loadUserByUsername()가 아닌 다른 인터페이스를 사용해야 할지도 모른다. 해당 상황에 대해 어떻게 대처를 할 수 있을까? 👣 AuthenicationManager 작동 원리 파악 우선 AuthenicationManager의 구현체, 즉 ProviderManager가 AuthenticationProvider를 선택하는 과..

👣 개요 나의 의문점은 UserDetailsService와 UserDetails 인터페이스는 모든 AuthenticationProvider에서 요구하냐는 것이었다. 때문에 관련 질문을 ChatGPT에게 물어봤다. 물론 답변은 이렇게 나왔으나 ChatGPT는 자신이 모르는 정보라도 아는 것 마냥 거짓말을 하는 경우가 자주 발생하기 때문에 해당 사실을 파악하기 위해 직접 코드를 확인하기로 했다. 👣 AuthenticationProvider 구현체들 코드 분석 우선 AuthenticationProvider 구현체들의 목록은 다음과 같다. 모든 클래스를 전수 조사하는 것은 쉽지 않기에 대표적인 몇몇 클래스로 확인하고자 했다. AbstractUserDetailsAuthenticationProvider Abstra..

👣 개요 Spring Security를 다루면서 들었던 의문점들을 해소하고자 해당 게시물을 작성하게 되었다. 해당 게시물에서는 인증 과정에서 일어나는 과정들을 상세히 다루고자 하며 Spring Security 내에서 일어나는 이벤트들에 중점적으로 다루며 코드 분석 중심으로 작성한다. 👣 Architecture 인증 과정 순서는 그림에 명시되어 있어서 설명은 생략한다. 👣 UserDetailsService 구현은 항상 요구되는 것인가? UserDetailsService 구현은 항상 요구되는 것인가? 👣 개요 나의 의문점은 UserDetailsService와 UserDetails 인터페이스는 모든 AuthenticationProvider에서 요구하냐는 것이었다. 때문에 관련 질문을 ChatGPT에게 물어봤다..

👣 개요 해당 게시물은 프록시를 이용해서 객체의 그래프 탐색에서 지연 로딩을 하는 방법에 대해 서술할 것이다. 👣 프록시 연관된 엔티티를 조회하는 방법은 2가지가 있다. 즉시 로딩 : 원래 엔티티를 조회할 때, DB에서 같이 불러오는 방법 지연 로딩 : 원래 엔티티는 엔티티대로 조회하고 연관된 엔티티를 호출할 때, 그때서야 DB에서 추가적으로 로드하는 방법 지연로딩을 실현시키기 위해 연관된 엔티티를 담는 필드에 실제 엔티티를 대입하는 것이 아니라 가짜 객체를 담고 해당 객체를 호출할 때, DB에서 조회하도록 설정한다. 이것을 프록시 객체라고 한다. // 실제 객체 호출 Member member = em.find(Member.class, 1L); // Proxy 객체 호출 Member member = em..

👣 개요 오늘은 목요일이라서 주특기 1주차의 내용을 토대로 시험을 봤다. 내용은 회원 일괄 조회 API와 회원 단일 조회 API를 구현한 서버 구축이었다. 해당 시험을 응시한 뒤, '자바 ORM 표준 JPA' 책을 읽으면서 블로그에 기록했다. 6장 다양한 연관관계 매핑 👣 개요 해당 게시물에서는 '다대일', '일대다', '일대일', '다대다' 의 연관관계를 다룰 예정이었다. 하지만 앞선 5장과 다소 중복이 많기 때문에 '다대다' 관계에 대해서만 다루고 넘어갈 것이다 ikadnorth.tistory.com 7장 고급 매핑 👣 개요 해당 게시물은 OOP와 SQL에서의 간극을 메꾸는 여러 기술을 나열하는 방식으로 서술된다. 아직 OOP와 SQL 사이에 간극이 존재하는데 내용은 다음과 같다. 1. OOP의 상속..