Spring Boot의 공통 프로세스 처리
- 위 그림에서 아쉬운점 AOP의 위치
: AOP는 어디서든 쓸 수 인터셉터와 컨트롤러 사이뿐만아니라!
- DispatcherServlet: 순서를 결정해서 그에 맞게 불러주는 친구, 스케쥴링, http 프로토콜로 들어오는 모든 요청을 가장 먼저 받아 알맞은 컨트롤러에 위임해주는 프론트 컨트롤러
- HandlerInterceptor: 핸들러로 가는애를 인터셉트 낚아채서 값을 체크, 검사하는 용도로만 사용함, 데이터를 건들지 않음
로그인 체크,
- 인터셉터: 요청에 대한 작업 전(후) 가로채어 공통 작업 수행
- res/req 낚아채서 (데이터 접근 가능 but,)
직접 다루는 일은 없어야 함!데이터를 바꾸면 안된다!- 사용예시
: 로그인 여부 체크, 검사
- 사용예시
@Configuration //스프링아 나 이 파일 설정파일로 쓸거야
public class CustomWebMvcConfigurer extends WebMvcConfigurationSupport {
@Override
protected void addInterceptors(InterceptorRegistry registry) {
registry.addInterceptor(new MyInterceptor())
.addPathPatterns("/**");
}
}- registry(feat.MSA)
모듈 간 소통 어떻게? 서로의 주소를 알아야하잖아?!
아이디어1💡 : 대신 전달하는 전달자 역할을 하는 친구를 하나 두자!
그런데!
대신 전달자 역할 친구: 야 나 전달만 하고 싶어 주소록 관리까지 하는게 너무 힘들어!
전달하는 친구의 부하를 너무 크다ㅠ^ㅠ 부하를 줄일 방법은?
아이디어2💡 : 주소를 관리하는 친구를 따로 두자!
위 그림과 같이 주소를 관리하는 친구를 따로 두고 요청이 들어오면 주소록 친구에게 주소를 받아서 소통하는 방식을 채택함.
- 여기서 주소록 역할을 하는 친구가 registry
- 대신 전달해주는 친구가 load balancer
필터 ~ 인터셉터
✔️ 필터~인터셉터 어떻게 구동될까?🧐
- 성공적으로 Res 날아올때
- 404처럼 처리할 수 없는 요청이 날아올 때
- 아예 예외가 터져버렸을 때(/error)
🌟WebMvcConfigurationSuppor
- 잘못된 요청을 보냈을 때!
디스패처 서블릿이 일 시킬 게 없음 즉, 요청을 받는 컨트롤러가 없음
: 요청이 틀리면 전달해줄값이 없으면 받아줄 컨트롤러가 없으면 filter로 돌아가게 됨.
그럼 왜 로그가 두 번 찍히는 걸까?
요청이 받아주지 않으면 왜 response안오지? 라고 생각하고, 먼저 돌아 나가고, 핸들러 인터셉터는 할 일 하고 나감!
그래서 로그가 2번 찍히는 것!
즉, exception 에러가 터지면 controller로 다시 요청이 가서, 두바퀴돌기 때문!
- 올바른 요청 보냈을 때!
디스패처 서블릿이 리퀘스트가 날라오면 일 시킬거리인 요청만 보내기 때문에 잘 나옴 나어디 줄데 있나 있으면 컨트롤러로 보냄 핸들러 인터셉터할일 하기..
vs @autoConfiguration 자동등록해드릴게 자동등록안해줄게
🌟 WebMvcConfigurer
-
잘못된 요청
-
올바른 요청
역할
-
Data Binding: 잭슨, 역직렬화/직렬화(interceptor), requestBody
-
validation
-
Handler exception resolver: exception이 터지면 잡아줌
-
filter: log 찍기 가능, 헤더관련된 것 처리, 인코딩(헤더값에 존재) 변환 처리, XSS 방어
- ServletRequest/ServletResponse 객체 변경 및 조작 수행 가능
- WAS 내의 ApplicationContext에서 등록된 필터가 실행됨.
➡️ 스프링이 알아야 한다! 스프링아 이거 필터니깐 봐줘! ➡️ 에노테이션 존재 ➡️ spring context는 bean 밖에 존재하는데 어떻게 스프링이 스캔할까?➡️@serveltComponentScan
-
chain.doFilter
@Override
public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain)
throws IOException, ServletException {
HttpServletRequest req = (HttpServletRequest) request;
HttpServletResponse res = (HttpServletResponse) response;
String requestURI = req.getRequestURI();
System.out.println("Filter Request - " + requestURI);
chain.doFilter(request, response); //필터가 이 사이에서 실행될 것
System.out.println("Filter Response - " + requestURI);
}
다음 필터나 마지막 필터로 넘겨주는 것 (나 방금 이 리퀘스트 지나왔거든!)
다음 리스펀스 들고 다음 리퀘스트로 넘겨주는 것
💡OWASP(Open web Application Security project)
⚠️ 웹이 공격을 당하는 방법
1. SQL Injection
2. XSS: 버튼을 누르면 숨겨진 스크립트가 날라감
3. CSRF(Cross Site Request Forgery): 사용자인척 웹 취약점을 공격
시큐리티 with 필터, 인터셉터
- 필터: 시큐리티 먹일까 말까 고민! 필터 씌울까말까 체인을 걸까 말까?
- 인터셉터: 필터로 시큐리티를 먹임 로그인을 해야만 들어갈 수 있도록 하고 싶음. 필터가 걸렸으면 인터셉터가 등장해서 체크해 드림! 사전 권한 체크
@gari_guri