Project Winter 지난 #3-Contoller 기능 구현 중 문제에서 생긴 bean 관련 문제를 해결하고 다시 컨트롤러 기능을 구현했다. 원랜 인터페이스 기반 컨트롤러 기능만 일단 구현하려 했지만 bean 기능을 구현한 김에 애노테이션 기반 컨트롤러까지 진행했다. 컨트롤러 인터페이스 기반 컨트롤러 인터페이스 package com.project.winter.mvc.controller; import javax.servlet.http.HttpServletRequest; import javax.servlet.http.HttpServletResponse; public interface Controller { String handleRequest(HttpServletRequest req, HttpServl..
Project Winter 원래 애노테이션 기반으로 싱글톤 빈을 런타임시에 생성/관리 해주는 기능은 프로젝트 막바지에 개발하려 했다. 하지만 지난번 컨트롤러 기능 개발 중 컨트롤러 매핑 문제가 있었고, 문제 해결 방법으로 @Configuration 애노테이션이 붙은 설정 클래스에서 컨트롤러를 매핑해주기로 했다. 이 기능을 구현하기 위해 애노테이션 기반 빈 객체 생성 기능을 먼저 개발하였다. Annotation 우선 애노테이션은 위와 같이 다섯개를 미리 만들어 뒀다. @Component @Target({ElementType.TYPE}) @Retention(RetentionPolicy.RUNTIME) public @interface Component { } 애플리케이션이 실행하면서 생성할 빈을 찾을 때, @..
Project Winter Controller 기능 개발 서버 기능을 구현 후 예정대로 Controller 기능 개발을 하던 중 문제를 만났다. Controller interface Controller { public Object handle(HttpServletRequest req, HttpServletResponse res); } 이렇게 컨트롤러 인터페이스를 만들고 이를 구현한 컨트롤러 클래스들을 실제 핸들러로 사용하고자 했다. HandlerMapping public interface HandlerMapping { void init(); Object findHandler(HttpServletRequest req); } HandlerMapping 을 구현한 클래스로 http method, uri 를 C..
Project Winter 본격적으로 프로젝트를 시작하기 앞서, Spring의 핵심인 DispatcherServlet을 생성하였다. DispatcherServlet은 WAS 에서 받은 모든 Http 요청을 받은 다음에, 각 uri가 매핑된 컨트롤러를 찾아 개발자가 정의한 작업 수행을 호출하는 역할을 한다. 진행중인 프로젝트에서도 동일하게 'DispathcerServlet'이라는 이름으로 Servlet을 등록해 모든 요청을 받게 하였다. DispatcherServlet @WebServlet("/") public class DispatcherServlet extends HttpServlet { private static final Logger log = LoggerFactory.getLogger(Dispat..
Project Winter 22년 4분기 즘, 백엔드 엔지니어로 전향 이직을 해야겠다는 마음을 먹고 스프링을 꾸준히 공부해왔다. 핑계가 섞여있긴 하지만 회사 업무와 병행하면서 부족한 부분을 채우려 하니 많은 공부를 하진 못했다. 애초에 지금 회사 취업 한것도 국비학원에서 연계로 취업한거라 실력이 좋은 상태로 취업한것이 아니었다. 그 상태에서 다른 취준생과 겨룰만한 실력까지 끌어 올리려니 공부할게 많다 느껴졌다. 아무튼 이렇게 공부를 하면서 스프링 동작 원리를 배우다 보니 단순히 보고 따라하기만 해선 한계가 있다 느껴졌고, 한번 스프링 프레임워크의 동작하는 방법을 따라 프레임워크를 만들어보고자 생각을 했다. 이름은 Project Winter. Winter 스프링 이름의 유래(나무위키)를 보면 '스프링'이라..
[Node.js/Express.js] Session, Interceptor 기능 개발 이전까지 세션과 인터셉터를 모두 개발 완료했다. 이제 매 요청 전 세션만 체크해주면 된다. 일단 해당 기능 적용 전 이전 글에서 Request 객체에 세션과 관련된 함수를 추가해주는 기능을 인터셉터로 변경해줬다. SessionManagerInterceptor class SessionManagerInterceptor extends HandlerInterceptor { /** * @type {SessionFactory} */ #sessionFactory; /** * @param {SessionStore} store */ constructor(store) { super(); this.#sessionFactory = new S..
[Node.js/Express.js] Session, Interceptor 기능 개발 지난 포스팅까지 세션 기능 개발을 완성했다. 요청이 왔을때, 서비스 로직을 수행하기 전 세션을 체크해서 권한이 있는 이용자의 요청인지 체크를 해주면 된다. 일전에 개발한 기존 세션기능은 모든 핸들러 함수 시작부분에 세션 Map을 뒤져 세션이 존재하는지 체크하는 로직을 일일이 넣어줬었다. 이번에 그런 수고를 줄이고자 인터셉터를 개발하기로 했다. HandlerInterceptor class HandlerInterceptor { /** * @param {Request} req * @param {Response} res * @return {boolean} */ preHandle = (req, res) => { return tr..
[Node.js/Express.js] Session, Interceptor 기능 개발 지난번 개발한 세션의 구조적인 변경을 진행했다. 이유는 현재 사내 프레임워크는 config.js라는 object에 필요한 정보들(DB host, port 등 과 같은 정보들)을 필드로 가지게 하고, 필요한 곳에서 모듈로 가져와 참조하는 방식을 사용했다. 그 중 Redis client와 관련된 정보도 있었다. 문제는 여기서 발생한다. 나는 config.js에 어떤 세션 스토어를 사용할지 명시할 계획이었으므로 개발자가 레디스 스토어를 사용하게 된다면 config.js에 const config = { redis: { socket: { host: 127.0.0.1, port: 6379 } }, sessionStore: Redi..
[Node.js/Express.js] Session, Interceptor 기능 개발 Redis로 세션을 저장하는 기능을 구현했지만, 흐름상 쿠키에 세션 key를 담아줄 경우 프록시서 버에서 쿠키를 탈취해 해당 key로 요청을 날리는건 마찬가지라는 생각을 했다. 요즘 JWT 같은 방법으로 인증관리를 구현한다고 알고있지만 아직 내가 잘 알지 못하고, 회사 분위기도 해오던 방법을 거스르는것에 반감이 있다보니 세션을 유지하고자 했다. JWT에 대해 알아볼때 봤던것이 쿠키에 httpOnly옵션을 줘서 클라이언트에서만 쿠키에 접근할 수 있도록 한다는 것을 참고해서 내가 구현한 세션/쿠키 방식에도 httpOnly 옵션을 추가하기로 했다. 쿠키 옵션 추가 기존 RedisSessionStore - geSession()..
[Node.js/Express.js] Session, Interceptor 기능 개발 HttpSession class class HttpSession { /** * @type { Map } */ #map #id constructor(id, map) { this.#map = new Map(); if (id) this.#id = id; if (map) this.#map = map; } /** * @param { string } name * @return { any } */ getAttribute = (name) => { return this.#map.get(name); } /** * @param { string } name * @param { any } attr * @return { void} */ setA..
