Goyummy

@RestController public class HelloController { @GetMapping("/hello-v1") public String helloV1(HttpServletRequest request) { String data = request.getParameter("data"); //문자 타입으로 조회 Integer intValue = Integer.valueOf(data); //숫자 타입으로 변경 System.out.println("intValue = " + intValue); return "ok"; } @GetMapping("hello-v2") //@RequestParam을 사용하면 스프링이 중간에서 타입 변환을 해줌 public String helloV2(@RequestParam..

API는 각 오류 상황에 맞는 오류 응답 스펙을 정하고, JSON으로 데이터를 내려주어야 한다. 스프링 부트가 제공하는 BasicErrorController는 HTML 페이지를 제공하는 경우에는 편리하지만, API 오류 처리는 각각의 컨트롤러나 예외마다 서로 다른 응답 결과를 출력해야 할 수도 있기 때문에 복잡하다. 'IllegalArgumentException'이 일어나고 아무런 처리를 안해주면 500 에러가 발생하는데 이것을 400에러로 바꾸어 주려면 'ExceptionResolver'를 활용해야 한다. HandlerExceptionResolver 활용 예외 상태 코드 반환 예외를 response.sendError(xxx)로 변경해서 서블릿에서 상태 코드에 따른 오류를 처리하도록 함 이후 WAS는 서..

서블릿의 예외 처리 방식 Exception response.sendError(HTTP 상태 코드, 오류 페이지) 서블릿은 Exception이 발생해서 서블릿 밖으로 전달되거나 response.sendError()가 호출되었을 때 설정된 오류 페이지를 찾는다. 예외 발생 흐름 WAS(여기까지 전파)

스프링 인터셉터 스프링 인터셉터는 서블릿 필터와 비슷한 기능을 제공하지만 훨씬 더 많은 기능을 제공한다 스프링 인터셉터 흐름 HTTP 요청 -> WAS -> 필터 -> 서블릿 -> 스프링 인터셉터 -> 컨트롤러 스프링 인터셉터는 디스패처 서블릿과 컨트롤러 사이에서 호출됨. 스프링 인터셉터는 스프링 MVC가 제공하는 기능이기 때문에 결국 디스패처 서블릿 이후에 등장하게 된다. 스프링 MVC의 시작점이 디스패처 서블릿이다. 스프링 인터셉터 제한 HTTP 요청 -> WAS -> 필터 -> 서블릿 -> 스프링 인터셉터 -> 컨트롤러 //로그인 사용자 HTTP 요청 -> WAS -> 필터 -> 서블릿 -> 스프링 인터셉터(적절하지 않은 요청이라 판단, 컨트롤러 호출X) //비 로그인 사용 스프링 인터셉터 체인 H..

쿠키의 보안 문제 쿠키에 memberId를 넣어서 사용하면 보안상의 문제가 있을 수 있다. 해커가 memberId를 바꾸어 다른 유저의 정보를 빼가거나 조작할 수 있다. 이를 막기 위해서는 쿠키에는 유저의 중요한 정보가 담겨 있으면 안되고, 쿠키에 사용되는 id가 시간이 지나면 사용할 수 없도록 만료되어야 한다. 그래서 세션 저장소를 이용해 UUID라는 예측할 수없는 id를 저장하여 사용해야 한다. 이렇게 만든 id를 쿠키에 담아 사용하면, 쿠키에는 유저의 중요한 정보가 담기지 않고, 예측할 수도 없다. 세션 세션 관리가 제공해야 하는 기능 세션 생성 sessionId 생성 (임의의 추정 불가능한 랜덤 값) 세션 저장소에 sessionId와 보관할 값 저장 sessionId로 응답 쿠키를 생성해서 클라이..

앞에서 검증1에서 한 것을 검증 Annotation을 이용하여 간단하게 할 수 있는 방식이다. @Data public class Item { private Long id; @NotBlank private String itemName; @NotNull @Range(min = 1000, max = 1000000) private Integer price; @NotNull @Max(9999) private Integer quantity; ... @PostMapping("/add") public String addItem(@Validated @ModelAttribute Item item, BindingResult bindingResult, RedirectAttributes redirectAttributes) { ..

데이터 베이스 커넥션 풀이나, 네트워크 소켓처럼 애플리케이션 시작 시점에 필요한 연결을 미리 해두고, 애플리케이션 종료 시점에 연결을 모두 종료하는 작업을 진행하려면, 객체의 초기화와 종료 작업이 필요하다. 스프링 빈은 객체를 생성하고, 의존 관계 주입이 다 끝난 다음에야 필요한 데이터를 사용할 수 있는 준비가 완료된다. 따라서 초기화 작업은 의존 관계 주입이 모두 완료되고 난 다음에 호출해야 한다. 그런데 개발자가 의존 관계 주입이 모두 완료된 시점을 어떻게 알 수 있을까? → 스프링은 의존 관계 주입이 완료되면 스프링 빈에게 콜백 메소드를 통해서 초기화 시점을 알려주는 다양한 기능을 제공한다. 또한 “스프링은 스프링 컨테이너가 종료되기 직전에 소멸 콜백”을 준다. 따라서 안전하게 종료 작업을 진행할 ..

지금까지는 @Bean을 이용하여 설정 정보에 직접 등록할 스프링 빈을 나열했다. 하지만 이렇게 등록해야 할 스프링 빈이 수십, 수백개가 되면 일일이 등록하기도 귀찮고, 설정 정보도 커지고, 누락하는 문제가 발생할 수 있다. 그래서 스프링은 설정 정보가 없어도 자동으로 스프링 빈을 등록하는 컴포넌트 스캔이라는 기능을 제공한다. 이때, 스프링 빈의 기본 이름은 클래스명을 사용하되 맨 앞글자만 소문자를 사용한다. 만약 스프링 빈의 이름을 직접 지정하고 싶으면 @Component(”…”)를 사용하면 된다. @Autowired를 사용하면 생성자에서 여러 의존관계도 한번에 주입받을 수 있다. @Component public class OrderServiceImpl implements OrderService{ pri..