Session 도입하기

HTTP Session 사용하기.

@Service
public class UserService {
...
private final HttpSession httpSession;
...
public UserService(..., HttpSession httpSession) {
        ...
        this.httpSession = httpSession;
        ...
    }
}

httpSession을 사용할 때, 사용할 메소드마다 httpSession을 넣어줄 수 있지만, 생성자 주입으로도 사용이 가능하다.

싱글톤 스코프,세션 스코프, scoped proxy

userService는 스프링이 처음에 뜰 때부터 종료될 때까지 살아있다. 반면 httpSession은 유저가 접속해있는 동안에만 유지되어야 한다.
그런데 생성자 주입을 하게 되면 스프링의 스코프와 세션의 스코프가 모두 싱글톤 스코프로 같아져버리지 않을까??
답은 아니다. 스프링은 HttpSession을 생성자 주입할때, httpSession인스턴스를 동적 프록시로 생성하여 주입해준다. 이것을 Scoped Proxy라고 한다.
즉, 우리의 userService는 singleton scope를 가지며, HttpSession은 session scope를 가진다.

그럼 프록시 말고 진짜 httpSession 주입은 누가 언제 해주나?

스프링에는 기본적으로 tomcat이라는 서블릿 컨테이너가 있다. 이 서블릿 컨테이너가 세션에 대한 요청(session.setAttribute, session.getAtturibute 등)이 왔을 때 비로소 진짜 세션을 생성해서 주입해준다.

세션을 사용하면서 생겨난 변화

간편해진 userRole에 대한 검증

세션을 사용하게 되면서, userId와 userRole을 담고있는 세션유저 클래스를 만들었고 이 세션유저 객체를 세션 저장소에
jsessionID--["user",SessionUser] 형태로 담아두었다.
따라서 이제는 userRole에 대한 검증을 진행할 때 userDB를 찌를 필요가 없어지고,

SessionUser sessionUser = (SessionUser) httpSession.getAttribute("user");

로 해서 세션유저를 가져온 뒤에 기져온 세션유저의 userRole에 대해 검증하기만 하면 되었다.