웹 개발에서 오류는 사용자 요청에 의한 페이지오류가 있고, API로 요청을 왔을때 발생하는 API오류가 있습니다.사용자 요청에 의한 오류페이지 제공은 스프링에서 제공되는 BasicErrorController를 사용하면 따로 로직을 개발하지 않고도 에러페이지를 만들수 있는데 API요청에 의한 오류는 많은 경우에서 발생이 가능하기 때문에 세밀한 관리가 필요합니다.@Slf4j@RestControllerpublic class ApiExceptionController { @GetMapping("/api/members/{id}") public MemberDto getMember(@PathVariable("id") String id) { if (id.equals("ex")) { ..
spring
ValidationBindingResult를 ModelAttribute뒤에 두어 요청에서 받아온 값에 오류가 있을경우 처리Filed인 경우 - rejectValuevoid rejectValue(@Nullable String field, String errorCode, @Nullable Object[] errorArgs, @Nullable String defaultMessage);예시bindingResult.rejectValue("itemName","required");bindingResult.rejectValue("price","range",new Object[]{1000,1000000},null); Object인경우 - rejectvoid reject(String errorCode, @N..
웹 사이트에서 예외는 언제나 발생할 수 있기때문에 에러에 대한 페이지 또한 관리가 필요합니다. 기본적으로 생각할 수 있는 404, 500등이 생각이 납니다. 기존 예외 페이지를 관리하는 방법은 web.xml에 에러코드에 대한 페이지를 등록하는 방법이 있는데 스프링 부트에서 제공되는 기능으로 처리해보겠습니다.@Componentpublic class WebServerCustomizer implements WebServerFactoryCustomizer { @Override public void customize(ConfigurableWebServerFactory factory) { ErrorPage errorPage404 = new ErrorPage(HttpStatus.NOT_FOUN..
Interceptor는 Filter와 마찬가지로 웹 요청이 컨트롤러에 도착하기전에 먼저 작동할 수있는 기능을 제공합니다. Filter, Interceptor 실행 순서HTTP 요청 -> WAS -> 필터 -> 서블릿 -> 스프링 인터셉터 -> 컨트롤러 Filter와 Interceptor의 차이점Filter는 서블릿에서 제공하는 기술이고,Interceptor는 스프링MVC가 제공하는 기술입니다.둘다 공통적인 처리를 가능하게 하지만 적용되는 순서와 범위, 사용방법이 다릅니다. Interceptor메서드preHandle` : 컨트롤러 호출 전에 호출된다. (더 정확히는 핸들러 어댑터 호출 전에 호출된다.)preHandle의 응답값이 `true` 이면 다음으로 진행하고, `false` 이면 더는 진행하지 않는다..
필터는 사용자의 요청이 컨틀로러의 들어오기전에 수문장 역할을 하여 구분을 할 수있게 해주는 역할을 합니다.로그인이 되지 않은 사용자에게 회원정보화면을 들어가면 안되는 것처럼 회원정보 요청이 들어올때 로그인 여부를 필터에서 판별하여 로그인이 되어있지 않다면 로그인 페이지로 이동을 할 수있게 해줄수 있다. 필터 흐름HTTP 요청 -> WAS -> 필터 -> 서블릿 -> 컨트롤러위와같은 흐름 사이에 필터를 넣어주게 되면 필터는 체인처럼 여러 필터를 거칠수도 있다.필터에 사용되는 메서드@Slf4jpublic class LoginFilter implements Filter { @Override public void init(FilterConfig filterConfig) throws ServletExc..
웹 사이트에서 가장 흔한 기술이 로그인, 로그아웃일 것입니다. 한번 로그인을 하면 로그아웃을 하거나 시간이 지나지 않는 이상 사이트를 이용하는 동안 계속해서 사이트는 저의 존재를 구분하여 사용이 가능하게 해줍니다. 이때 사용되는 기술이 쿠키와 세션입니다.흔히 간단하게 알고있는 지식으로는 쿠키는 클라이언트에 보관이 되고 세션은 서버에서 저장이 된다고 알고 있습니다.쿠키만 사용하면 안될까?기본적으로 정보를 저장하는데 있어서 클라이언트에만 의존하게 된다면 보안에 취약하다고 생각하게 됩니다.F12키를 눌러서 네트워크에 보시면 현재 사용중인 쿠키의 정보가 그대로 노출이 됩니다. 정보가 그렇게 쉽게 노출이 되면 안되겟죠.. 세션만 사용하면 안될까?기본적으로 클라이언트에서 서버에 요청을 보낼때 매번 요청이 생성이 되..
Spring에서는 클라이언트에서 받아온 정보를 Validation을 이용하여 검증을 하였는데 Spring Boot에서 제공해주는 Bean Validation이라는 기능을 이용하여 조금더 수월하게 검증을 이뤄보려고 합니다. build.gradleimplementation 'org.springframework.boot:spring-boot-starter-validation' Item@Datapublic class Item { private Long id; @NotBlank private String itemName; @NotNull @Range(min = 1000, max = 1000000) private Integer price; @NotNull @Max(9999..
웹 사이트를 개발하다보면 같은 문구가 여러 페이지에서 반복해서 들어가는 경우가 많이 존재합니다.만약 모든곳에 직접 문구를 기입하는 와중에 특정 문구를 일괄로 바꿔야 하는 상황이 생긴다면 해당 문구가 사용되는 페이지를 모두 찾아가면서 직접 바꿔야하는 수고가 발생 합니다. 그렇기 때문에 그런 메세지들은 한곳에 보관하여 값을 불러와 화면에 뿌려준다면 매우 편리하게 관리가 가능해 질 것입니다. application.propertiesspring.messages.basename=messages앞으로 메시지를 관리할 파일의 이름을 messages.properties로 할 것이며 application.properties에 위처럼 명시해줍니다. messages.propertieslabel.item=상품 label.it..
