새싹 코더의 TIL

@Mapper

• Spring IoC 컨테이너에 Bean으로 등록
• 해당 인터페이스에 등록된 SQL Annotation을 토대로 실제 SQL문을 실행시켜 준다.
• 스프링 3이상 버전부터 mapper.xml 대신 interface 클래스의 Annotation을 통해 SQL을 사용할 수 있다.

@Mapper
public interface TopMenuMapper {

    @Select("SELECT board_info_idx, board_info_name FROM board_info_table")
    List<BoardInfoBean> getTopMenuList();

}

서블릿은 다음 2가지 방식으로 예외 처리를 지원한다.
1. Exception(예외) - 500처리 
2. response.sendError(HTTP 상태코드, 오류 메시지)
->직접 오류메시지 담아서 처리

1.Exception
먼저 스프링부트가 제공하는 기본 예외페이지를 꺼둔다.
- application.properties

server.error.whitelabel.enabled=false

package hello.exception.servlet;

import lombok.extern.slf4j.Slf4j;
import org.springframework.stereotype.Controller;
import org.springframework.web.bind.annotation.GetMapping;

@Slf4j
@Controller
public class ServletExController {

    @GetMapping("/error-ex")
    public void errorEx(){
        throw new RuntimeException("예외발생!");
    }
}

실행 결과:

HTTP Status 500 – Internal Server Error
:서버 내부에서 처리할 수 없는 오류 

exception이 WAS까지 전달되면 서버에서 처리할 수 없는 예외로 간주하고 500으로 상태코드를 만들어서 반환해주고 페이지를 뿌려준다. 

exception터진건 무조건 500오류로 나간다. 

response.sendError(HTTP 상태코드, 오류메시지)
: 오류가 발생할때 HttpServletResponse가 제공하는 sendError라는 메서드 사용할 수 있다. 

@GetMapping("/error-404")
public void error404(HttpServletResponse response) throws IOException {
response.sendError(404, "404 오류!");
}
@GetMapping("/error-500")
public void error500(HttpServletResponse response) throws IOException {
response.sendError(500);
}

sendError흐름

response.sendEroor()호출하면 response내부에는 오류가 발생했다는 상태를 저장해둔다.
그리고 서블릿 컨테이너는 고객에게 응답전에 response에 sendError()가 호출되었는지 확인한다.
만약 호출되었다면 설정한 오류고드에 맞추어 기본 오류페이지를 보여준다.

*본 게시물은 인프런 스프링MVC2편 - 백엔트 웹 개발 활용 기술 강의를 토대로 작성했습니다.

서블릿 필터와 마찬가지로 웹과 관련된 공통 관심사항을 해결하는 기술이다.
필터는 서블릿이 제공하는 기술인 반면, 인터셉터는 스프링 MVC가 제공하는 기술.
둘다 웹관련 공통 관심사항을 처리하지만, 적용되는 순서와 범위, 사용방법이 다르다.

*스프링 인터셉터 흐름
HTTP요청 -> WAS -> 필터 -> (디스페처)서블릿 -> 스프링 인터셉터 -> 컨트롤러

*스프링 인터셉터 제한
HTTP요청 -> WAS -> 필터 -> (디스페처)서블릿 -> 스프링 인터셉터 -> 컨트롤러 // 로그인 사용자
HTTP요청 -> WAS -> 필터 -> (디스페처)서블릿 -> 스프링 인터셉터(적절치 않은 요청이라 판단, 컨트롤러 호출X) // 비 로그인 사용자

*스프링 인터셉터 체인
HTTP요청 -> WAS -> 필터 -> (디스페처)서블릿 -> 인터셉터1 -> 인터셉터2 -> 컨트롤러 
: 필터와 마찬가지로 중간에 인터셉터 자유롭게 추가할 수 있다. 

public interface HandlerInterceptor {
    default boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {}
    
    default void postHandle(HttpServletRequest request, HttpServletResponse response, Object handler, @Nullable ModelAndView modelAndView) throws Exception {}
   
    default void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, @Nullable Exception ex) throws Exception {}
}

preHandle: 컨트롤러 호출 전, 호출된다. 응답값이 true면 다음으로 진행하고, false면 진행하지 않는다.
postHandle: 컨트롤러 호출 후
afterCompletion: http 요청이 완전히 끝날때, 뷰가 랜더링 된 이후에 호출된다. / 예외가 발생해도 호출된다.

예외가 발생하면 postHandle은 호출되지 않으므로 예외와 무관하게 공통처리를 하려면 afterCompletion()을 사용해야한다. 

필터: 서블릿이 지원하는 '수문장'이다.

필터흐름
HTTP요청 -> WAS(서버) -> 필터 -> 서블릿 ->컨트롤러 

* 필터는 특정 URL피턴에 적용할 수 있다. /* 라고 하면 모든 요청에 필터가 적용된다.
* 스프링을 사용하는 경우의 서블릿은 스프링의 디스패쳐 서블릿이다. 

필터 제한
HTTP요청 -> WAS(서버) -> 필터 -> 서블릿 ->컨트롤러 //로그인 사용자
HTTP요청 -> WAS(서버) -> 필터(적절치 않은 요청이라 판단, 서블릿 호출X) //비 로그인 사용자

필터 체인
HTTP요청 -> WAS(서버) -> 필터1-> 필터2-> 필터3-> 서블릿 ->컨트롤러
: 중간에 필터를 자유롭게 추가할 수 있다. 
 EX) 로그를 남기는 필터를 먼저 적용하고 로그인 여부를 체크하는 필터 만들 수 있다. 

쿠키값은 임의로 변경될 수 있고
쿠키에 보관된 정보는 해킹될 수 있기에 

서버에 중요한 정보를 보관하고 연결을 유지하는 방법, 즉 세션으로 로그인처리해야 한다. 

동작방식:
1. 사용자가 로그인, 비밀번호 정보를 저장하면 서버에서 해당 사용자가 맞는지 확인한다.
2. 그럼 서버에서 추정불가능한 랜덤값, 즉 'UUID'를 만든다.
3. 서버는 세션 저장소를 만들고 그 값(UUID)을 토큰 키(sessionId)로 사용한다. 
4. 값(value)은 회원객체로 매핑한다.
5. 그렇게 서버에 sessionId와 value가 저장된다. 세션아이디를 알면 회원 객체를 꺼낼 수 있다.  

6. 서버는 클라이언트에 'sessionId만 쿠키에 담아서 전달한다.  
7. 클라이언트는 쿠키저장소에 sessionId 정보가 담긴 쿠키를 보관한다.  

*회원과 관련된 정보는 전혛 클라이언트에 전달되지 않는다.
*추정 불가능한 세션id만 쿠미를 통해 클라이언트에 전달한다.

8. 웹브라우저가 특정페이지 들어가면 쿠키를 전달하는데, sessionId 정보를 서버로 전달한다.
9. 서버에서는 세션저장소를 뒤져서 키(sessionId)에 맞는 value(회원객체)가 있는지 확인한다.