Week3 TIL 리스트업
- 14일차: Spring Boot default-DB/ @Component/ scheduler / MYSQL연동 / gitIgnore /EC2 배포
- 15일차: @JsonIgnore / request / @Controller / HTTP / @ResponseBody / MVC 동작원리 /CS 스터디
- 16일차: HTTP Request message / DI / IoC 컨테이너
- 17일차: 인증, 인가 / 쿠키, 세션 / Spring Security
- 18일차: OAuth2.0 / SSO / JWT (항해일지 18일차)
- 19일차: Spring Test Framework
1. 회고
1) 14일차
- application.properties에 DB관련 설정을 하지 않았는데, h2 DB에 자동으로 연결되었던 것
- @Component의 개념에 대해 학습
- @SpringBootApplication 안에 있는 @ComponentScan이 @Configuration에 등록한 @Bean들을 자동으로 생성해준다.
- Spring scheduler 사용법
- MYSQL RDS 연동과 EC2 우분투에 배포하기
- DB관련 계정 정보는 깃허브에 올라가지 않도록 gitignore에 등록하기
2) 15일차
- @Entity 클래스에서 @JsonIgnore를 붙인 @Column은 Json 직렬화 과정에서 빠진다. 통신 과정에 빠져야하는, 이를테면 비밀번호와 같은 것들을 쉽게 뺄 수 있다.
- @Controller를 쓰는 이유 -> Servlet 방식과 비교하여 정리
- Http Response 메세지: 컨트롤러의 return에 해당하는 부분인데, @ResponseBody와 String 타입 여부에 따라 크게 구별된다.
- Spring MVC 동작 원리
3) 16일차
- Http Request 메세지: Controller에 도착한 Request 메세지를 어떻게 받을 수 있는가? (어노테이션 별 정리)
- Service, Repository는 왜 필요한가? 모든 기능을 담은 Controller 만들어서 직접 비교해봄
- DI, IOC: 객체 지향의 강력한 아군
4) 17일차
-
Spring Security
-
오늘 복습하며 과제에 구현하며 정리
-
회원가입 과정은 @Entity User 객체를 하나 생성하는 과정으로, 주로 Validation check하는 과정이다.
-
스프링 시큐리티의 주된 구현은 로그인 과정에서 발생한다.
-
위 그림이 정말 핵심만을 담은 것 같다는 생각이 들었다.
-
구현한 로그인 방식은 총 2가지로 로그인폼 / SSO 였다.
-
로그인 폼의 경우 클라이언트가 입력한 username/password가 Authentication Manager에게 전달되고, 이는 UserDetailsService에게 전달되어 DB에서 같은 username의 계정정보를 가져온다.
-> loadUserByUsername -
이 후 찾아온 User 객체를 UserDetail의 생성자에 담아 보낸다.
-
UserDetail에선 해당 User 정보에 대해 getter를 비롯한 다양한 정보를 가져올 수 있는 메서드들을 정의한다. 그중 getAuthorities() 부분은 실제 권한을 부여하는 메서드이다.
-
이렇게 User 정보를 담은 UserDetail은 Authentication Manager에 의해 클라이언트가 입력한 값과 비교되고, 일치한다면 Session에 로그인한 유저의 정보가 등록된다.
-
이렇게 생성된 세션 정보는 컨트롤러 메서드의 파라미터 자리에@AuthenticationPrincipal UserDetail userDetail로 불려와 자유롭게 사용 가능하다. (유저 정보를 사용해야되는 경우가 많았는데 참 편리하다는 생각이 들었다.)
-
-
➕ 오늘 구현한 과제 - 스프링 시큐리티, OAuth2.0 구현 코드
➕ 오늘 구현한 과제 - 댓글 CRUD 구현 코드
5) 18일차
-
OAuth 2.0
-
위 방식으로 카카오 계정으로 로그인하는 과정 또한 구현했다.
-
순서는 위 그림과 같은데, 역시 로그인하여 인가를 받는 과정이 중점적인 구현부이다.
-
클라이언트가 카카오 계정 로그인 동의를 완료하면 콜백함수로 지정한 URI로 인가 code가 넘어온다.
-
이를 받고 부터는 웹과 웹 간의 통신을 구현한다.
-
받아온 인가 코드로 카카오에게 액세스 토큰을 요청한다.
-
액세스 토큰을 성공적으로 받아왔다면, 이 토큰을 다시 보내 계정 정보를 받아온다.
-
받아온 카카오 계정 정보를 가지고 신규 회원이라면 User 객체를 생성하여 강제 로그인 / 기존 회원이라면 기존 User 객체에 카카오 id만 set해주고 강제 로그인
-
강제 로그인은 UserDetail(kakaoUser) 생성하고 UsernamePasswordAuthenticationToken 생성한 뒤, SecurityContextHolder에서 컨텍스트를 불러와 setAuthentication해주면 된다.
-
6) 19일차
- Spring 테스트 프레임워크
- TDD의 중요성 (애자일과 연관지어 탐구하고 올바른 개발 습관 들이기)
- 단계 별 (범위 별) 테스트 구현 과정 학습
2. DI, IoC, Bean
3. TIL
- 일요일은 WIL만 썼었는데, 오늘은 과제 잠깐 본다는게 9to11으로 이어졌다..🤦♂️🤷♀️ 내 일요일..
- 오늘 이렇게 오래 걸린 이유는 MYSQL 때문이었다.
- 댓글 CRUD 구현은 사실 이미 구현한 것들과 많이 겹쳐서 간단히 구현하고 쉬려고 했는데, 분명 분명 분명.. 오류 없이 잘 구현했다 싶었는데 계속 오류에 빠졌다.
- 스프링 기동할 때 부터 나타나는 InputStream관련 오류 (기동엔 문제 없었다.) + @ClassNotFoundException (구글링 해봐도 나랑 겹치는 상황은 없었음.) + @Bean으로 등록한 녀석들을 못찾겠다는 오류..(순환 참조의 가능성을 따져봤으나 전혀 문제 없었음) + Field 값 Default 값이 없다는 오류(아니 해당 컬럼은 nullable도 true로 줬고 애초에 PK도 아닌데,,,)
- 이 길고 긴 오류의 흐름이 거진 4시간은 이어졌다. 진짜 시간 살살 녹았다.
- 아무리 봐도 MYSQL쪽 문제인 것 같아 application.properties에 MYSQL 연동 싹 지우고 h2로 연결하니 진짜 거짓말 처럼 내가 구현했던 코드들이 전부 정상적으로 작동했다. 굉장히 허탈.......................
- 이유를 찾아보니 spring.jpa.hibernate.ddl-auto=update 이부분 때문에 계속적으로 @Entity 값에 변화가 생길때마다 꼬이고 꼬이고 또 꼬여서 오류가 발생했던 거였다.
- update를 create로 바꿔 데이터를 싹 날려버리고 다시 update로 바꿔줬다. 이래서 구현단계 및 테스트 단계에서 h2 데이터 베이스를 쓰는구나 싶었다.
- 아직 제대로 배우지도 않은, 그냥 복붙해서 사용한 코드에서 오류가 나니까 정말 속상하다.. 얼른 심화 강의 4주차 듣고 알고쓰자!!!
- 오늘의 한풀이 끝. 내 일요일도 끝. 내일 부터 월요일 시작.. ㅎㅇㅌ..😢
