-
Spring security는 사실상 지금 알아둘 필요는 없다. 이게 어려운게 맞고 확장성이 너무 넓어서 한도끝도 없기 때문에 지금 할 난이도가 아니다. 그냥 필터에서 이런 처리를 하는구나만 보고 넘어가면 된다.
-
지금은 오히려 AOP랑 @Transactional만 하면 된다. 특히 Transactional은 꽤 심도있게 알아둘 필요가 있다!
-
나중에 카카오톡으로 가입하기 같은거 구현할때 생일을 수집한다고 하면, 그 생일값에 Null값이 들어와서 NPE이 터지는 경우 반드시 있음! NPE 처리를 잘 해야한다.
-
카카오 로그인 쓰다가 에러가 나면 코드도 따로 쓰는데, 에러코드도 우리가 아는게 아니라 003 이런 식으로 따로 나오게 된다. 그래서 이 에러코드 우리가 다 검색해서 원인분석 해야함.
-
OAuth를 쓰면 우리가 토큰을 보낸다 -> 우리 앱으로 등록한 사람이 실제 유효한 사용자인지, 유효한 정보인지를 체크.
myselectshop의 access토큰->카카오에서 받아온 토큰
그리고 이 받아온 토큰을 기반으로 우리가 또 토큰을 만듬 -> 이게 create토큰
- 액세스 토큰이랑 리프레시 토큰
세션 -> 우리쪽 리포지토리에 저장
토큰 -> 사용자 클라이언트에 저장. 탈취 위험 있음!
보안을 위해 토큰을 짧게 하자니 사용성이 너무 떨어지고, 사용성을 챙기자니 보안이 취약하고... 어쩌면 좋을까?
-> 토큰을 두개 쓰자! 액세스 토큰과 리프레시 토큰 이런 식으로.
-> 일반적으로 액세스 토큰은 좀 짧게, 리프레시 토큰은 좀 길게.
-> 리프레시 토큰이 유효한 동안은 둘이 비교해서 액세스 토큰을 재발급 해줌.
-> 그래서 액세스 토큰은 탈취되어도 다시 만들어주면 된다.
어? 그러면 액세스 토큰만 털어가는거에요?
-> 아니, 털어가긴 그냥 다 털어가지. 리프레시 토큰에 다른 처리를 해 주는 것.
리프레시 토큰은 read-only로 해놓는다거나, 리프레시 토큰은 유저쪽 말고 우리쪽의 서버에 저장해놓는다거나 하는 식으로 사용할 수 있음.
액세스 토큰이 유효하면 리프레시 토큰을 계속 재발급해주는 것도 있다.
여기까지 질문있는 사람?
@Controller 일때랑 @RestController일때 MVC?
- @Controller일때는 Dispatcher servlet이 View name을 View Resolver한테 던져주면 Resolver가 name에 맞는 view를 그려서 클라이언트에 반환해준다는데... 무슨 말인가요?
-> 그냥 HTML 파일 던져준다고. HTML 파일도 index니 login이니 이름이 있을 거 아냐. 그 이름에 맞는 애를 그대로 반환해준다는 얘기.
