Programming-[Backend]/Spring (76) 썸네일형 리스트형 [스프링 웹MVC-2] 17. API 예외 처리 - 스프링 ExceptionResolver 이전 글에서 Exception을 직접 처리하는 ExceptionResolver를 만들어보았다. Exception 종류에 따라 statusCode와 message를 넣은 뒤, ModelAndView를 반환하는 방식으로 진행했다. 이번에는 직접 만들지 않고, 스프링이 제공하는 ExceptionResolver를 편리하게 사용해본다. 1. 스프링 부트가 제공하는 ExceptionResolver 종류 스프링 부트에는 HandlerExceptionResolverComposite 이라는 파일에 다음 순서로 ExceptionResolver 들이 등록되어있다. 1. ExceptionHandlerExceptionResolver 2. ResponseStatusExceptionResolver 3. DefaultHandlerE.. [스프링 웹MVC-2] 16. API 예외 처리 - 스프링부트 기본 오류 처리, HandlerExceptionResolver 1. 서블릿 API 오류 처리 API 방식 오류 처리 이전 글에서는 4xx, 5xx 등 Http 상태코드에 따라 오류 페이지를 클라이언트에 보여주는 형식으로 처리했다. 상황에 따라 보여줄 페이지만 설정하면 되므로 상대적으로 간단한 방식이라 할 수 있다. 그러나, API 통신의 경우를 생각해보자. 만약 서버-서버간 API 통신을 한다고 생각해보면, HTML로 표현된 페이지를 보내서 통신을 할 수는 없다. 어떤 데이터 양식(ex. json 객체)으로 통신을 할지 규약을 정하고, 그에 맞게 데이터를 보내주어야 한다. 서블릿의 API 방식 오류 처리 이전 글에 이어서 진행을 했다면, WebServerCustomizer 클래스가 주석처리 되어있을 것이다. 주석을 풀고, 다시 Bean으로 등록하여 서블릿에 의해 A.. [스프링 웹MVC-2] 15. 예외 - 인터셉터와 스프링 부트의 오류 페이지 1. 인터셉터의 예외 처리 인터셉터의 예외 처리 방식과 설정 방법을 알아본다. LogInterceptor 작성 이전과 마찬가지로 LogInterceptor를 작성한다. 다만, 필터를 학습할 때와 마찬가지로 request.getDispatcherType()을 로그로 남기도록 한다. java/hello/exception/interceptor/LogInterceptor.java 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 @Slf4j public class LogInterceptor implements HandlerInterceptor { public static final String LOG_ID .. [스프링 웹MVC-2] 14. 예외 - 서블릿 오류 페이지 1. 서블릿 예외 발생 처리 방식 서블릿은 2가지 방식으로 예외 처리를 지원한다. Exception response.sendError(HTTP 상태코드, 오류 메시지) Exception이 발생하는 경우는 다시 2가지로 나뉜다. 자바 실행 통상 main 쓰레드를 실행하는 경우이며, 미리 짜놓은 코드에 의해 실행 중 예외가 발생하지 않고 main 메서드를 넘어서 예외가 발생하면 예외 정보를 남기고 쓰레드가 종료된다. 웹 애플리케이션 웹 애플리케이션은 요청별로 쓰레드가 할당되고, 서블릿 컨테이너 안에서 실행된다. 자바 실행의 경우와 마찬가지로 미리 짜놓은 try ~ catch 문 등으로 예외를 잡아내면 상관없지만, 예외를 잡지 못해서 서블릿 밖으로까지 예외가 전달되면 아래와 같은 도식으로 예외가 전파된다. WAS [스프링 웹MVC-2] 13. 로그인 - 스프링 인터셉터, ArgumentResolver 활용 1. 스프링 인터셉터의 특징과 흐름 스프링 인터셉터는 스프링 MVC가 제공하는 기술이다. 서블릿 인터셉터와 마찬가지로 웹의 공통 관심 사항을 처리하지만, 좀 더 정밀하게 설정이 가능하다. 인터셉터의 적용 순서는 다음과 같다. HTTP 요청 -> WAS -> 필터 -> 서블릿(DispatcherServlet) -> 스프링 인터셉터1 -> 스프링 인터셉터 2-> ... -> 컨트롤러 서블릿 필터에 비해서, request, response만 받는 것이 아니라 어떤 컨트롤러(handler)가 호출되는지 호출 받을 수 있고, modelAndView도 받을 수 있다. 그리고 preHandle, postHandle, afterCompletion 메서드 순으로 흐름이 진행된다. 구조 자체가 스프링 MVC에 특화되어 있.. [스프링 웹MVC-2] 12. 로그인 - 서블릿 필터 1. 서블릿 필터 개념 이때까지 만든 로그인 기능만으로는 사용자의 로그인 여부에 따라 웹페이지 내 특정 url로의 접속을 허용하거나 제한할 수 없다. 이런 기능을 지원하는 것이 서블릿 필터이다. 물론 로그인 여부만 검사하는 것이 아니라 컨트롤러에 접근 전에 미리 요청의 적절성을 검사해주는 기능 단위라고 이해하면 된다. 다음 글에서 배울 스프링 인터셉터도 마찬가지 기능을 제공한다. 만약 이런 기능들을 이용하지 않고 각 컨트롤러에서 로그인 여부를 직접 확인한다면, 로그인 여부를 확인하는 코드를 모든 컨트롤러들에 일일이 작성해주어야 할 것이다. 요청을 필터링 하는 기능은 각 컨트롤러에서의 공통 관심사이기 때문에, 공통 기능으로 통합하는 AOP 개념을 도입할 수 있지만, 웹과 관련된 기능을 공통화할때는 서블릿 .. [스프링 웹MVC-2] 11. 로그인 - 세션 활용 1. 쿠키의 보안 문제 쿠키는 클라이언트에서 서버로 전달하는 것이기 때문에 위·변조가 가능하다. 예를 들어 아래 사진과 같이 Application 탭에서 memberId 쿠키의 값을 임의로 변경할 수 있다. 이렇게 변경하면 마치 다른 memberId를 가진 사용자로 로그인 한것처럼 되어 정보를 탈취할 수 있게 된다. 또한 혹시 쿠키에 신용카드 정보나 민감정보를 담고 있는 경우, 나의 PC가 해킹을 당하거나 네트워크 전송 구간에서 정보를 탈취당하는 경우가 생길 수 있다. 그래서 다음과 같은 방법을 통해서 쿠키의 보안 취약점을 보완할 수 있다. 쿠키에 중요한 값을 넣지 않는다. 그리고 예측불가능한 랜덤값을 넣어준 다음 서버에서 토큰과 사용자 id를 매핑하여 인식하도록 한다. 그리고 토큰값은 서버에서만 관리하.. [스프링 웹MVC-2] 10. 로그인 - 기본 기능, 쿠키 적용 1. 프로젝트 생성, 도메인 정의 강의의 login 프로젝트를 가져와서 학습한다. 패키지 구조를 살펴보면, 크게 domain과 web으로 나눠져 있는 것을 볼 수 있다. 도메인 여기서 도메인이란, 화면, UI, 기술 인프라 등을 제외한 시스템이 구현해야하는 핵심 비즈니스 로직이 담긴 영역을 의미한다. 나중에 web이 다른 기술로 바뀌더라도 domain은 유지되어야 개선이 가능하다. 따라서 domain은 web을 의존, 참조하지 않도록 설계하는 것이 매우 중요하다. 2. 회원 가입 기능 개발 홈화면 작성 우선 home 화면을 만든다. templates 폴더에 home.html 파일을 복사한다. 회원 가입 기능 개발 이제 회원 가입 버튼을 누르면 회원가입이 되도록 만들어본다. 우선 회원 정보 클래스인 Mem.. 이전 1 2 3 4 5 6 ··· 10 다음
