qwef

스프링 인터셉터도 서블릿 필터와 같이 공통 관심사항을 해결하는 기술이다. 기능도 훨씬 강력하다. 흐름은 HTTP 요청 -> WAS -> 필터 -> 디스패처서블릿 -> 스프링 인터셉터 -> 컨트롤러 이다. 스프링 인터셉터는 스프링MVC의 기능이기 때문에, 결국 디스패처 서블릿 이후에 등장하게 된다. 스프링MVC의 시작점이 디스패처 서블릿 이니까. 스프링 인터셉터의 제한은 저 흐름에서 컨트롤러로 가는 것을 막는 것이다. 얘도 똑같이 체인 기능이 있다. 다음이 실제 스프링 인터셉터의 인터페이스이다. public interface HandlerInterceptor { default boolean preHandle(HttpServletRequest request, HttpServletResponse respons..

이제 로그인 하지 않았다면 상품관리 등의 페이지에 접근하지 못하도록 하는 필터 로직을 개발해 보자. @Slf4j public class LoginCheckFilter implements Filter { private static final String[] whitelist = {"/", "/members/add", "/login", "/logout", "/css/*"}; @Override public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException { HttpServletRequest httpRequest = (HttpServletReque..

간단하게 요청에 대한 로그를 남기는 필터를 구현해 봤다. @Slf4j public class LogFilter implements Filter { @Override public void init(FilterConfig filterConfig) throws ServletException { log.info("log filter init"); } @Override public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException { HttpServletRequest httpRequest = (HttpServletRequest) request; Htt..

필터는 서블릿이 제공 인터셉터는 스프링이 제공 예를 들자면 회원정보수정이나 이런 것들은 로그인 한 사용자만 들어올 수 있도록 해야 한다. 근데 지금은 링크태그를 안달아놔서 그렇지, 그냥 url에 치면 들어올 수 있다. 말 그대로 필터이다. 특정 조건을 만족하는 사용자만이 특정 url에 접근할 수 있도록 하는 것이다. 물론 회원정보 수정 등 컨트롤러의 로직에 일일히 다 쿠키검사를 하는 방법도 있겠지만.. 한 두개가 아닐 것이다. 게다가 만약 향 후 로그인에 관한 로직을 수정하게 된다면.. 이렇게 여러 로직들에서 공통적으로 관심을 가져야 하는 것을 공통 관심사 라고 한다. 회원 정보 수정, 삭제, 조회 등 사용자에 대한 로그인(인증)에 관심이 있다. AOP( https://qwefdg3.tistory.com..

세션 정보 확인 @Slf4j @RestController public class SessionInfoController { @GetMapping("/session-info") public String sessionInfo(HttpServletRequest request){ HttpSession session = request.getSession(false); if(session == null){ return "세션이 없습니다."; } session.getAttributeNames().asIterator() .forEachRemaining( name -> log.info("session name = {}, value = {}", name, session.getAttribute(name))); log.inf..

살짝. 업그레이드 한다. @GetMapping("/") public String homeLoginV3Spring(@SessionAttribute(name = SessionConst.LOGIN_MEMBER, required = false) Member loginMember, Model model) { if(loginMember == null){ return "home"; } model.addAttribute("member", loginMember); return "loginHome"; } @SessionAttribute(name = SessionConst.LOGIN_MEMBER, required = false) Member loginMember 이렇게 세션 받을 수 있다. 참고로 이거 있으면 받기만 하는거..

먼저 key이름 같은 건 자주 쓰니 public interface SessionConst { public static final String LOGIN_MEMBER = "loginMember"; } 아예 인터페이스에다가 public으로 String 해놔서 등록. @PostMapping("/login") public String loginV3(@Validated @ModelAttribute LoginForm loginForm, BindingResult bindingResult, HttpServletRequest request){ if(bindingResult.hasErrors()){ return "login/loginForm"; } Member loginMember = loginService.login(l..

세션기능 구현은 완료했고, 이제 적용하는 일만 남았다. 적용은 쉽다. @Slf4j @Controller @RequiredArgsConstructor public class LoginContoller { private final LoginService loginService; private final SessionManager sessionManager; @GetMapping("/login") public String loginForm(@ModelAttribute LoginForm form){ return "login/loginForm"; } @PostMapping("/login") public String login(@Validated @ModelAttribute LoginForm loginForm, B..

@Component public class SessionManager { public static final String SESSION_COOKIE_NAME = "mySessionId"; private Map sessionStore = new ConcurrentHashMap(); public void createSession(Object value, HttpServletResponse response){ String sessionId = UUID.randomUUID().toString(); sessionStore.put(sessionId, value); Cookie cookie = new Cookie(SESSION_COOKIE_NAME, sessionId); response.addCookie(cookie..

결국 중요한 데이터는 모두 서버에 저장해야 하며, 서버와 클라이언트 외에 추정 불가능한 무언가의 식별자가 있어야 한다. 전체적인 로직은 이렇다. 1. 클라이언트가 서버에 로그인아이디, 패스워드와 함께 로그인 요청을 한다. 2. 서버에서는 맞는 정보인지 찾아본다. 만약 맞다면, 세션 저장소에 예측할 수 없는 임의의 값(임의의값 + Hash나 UUID 등)을 세션id(일종의 key)로 넣고 value로 그 멤버의 정보를 저장한다. 3. 그 다음 쿠키로 이 세션 ID를 보낸다. 이러면 세션 아이디에서는 유저에 대한 정보를 전혀 예측할 수 없다. 또, 이 세션ID도 만약 무언가 외국 IP등 이상현상이 있으면 세션저장소에서 아예 지워버리거나, 또 대부분 이 세션을 짧게 (한 30분?) 유지시키고 그 후 파괴 시킨..