각 개발 팀 별로 Git Flow 운영하는 방식이 다를 수 있지만, 대게 1 commit per 1 feature 를 준수하는 경우가 많은데 이 때 하나의 Feature Branch 에서 두 개 이상의 커밋을 하나로 병합하기 위해서 Squash 를 사용할 수 있다.
[그림 1]
[그림 1]에서 두 개의 커밋을 병합하기 위해git rebase -i HEAD~N (N = 병합하고 싶은 커밋 수)를 터미널에서 입력하는데, 이 경우 두 개의 커밋을 하나로 병합하는 상황이므로 git rebase -i HEAD~2 를 입력한다.
Spring Framework의 Web Framework인 Spring MVC 와 인증, 인가 등 보안 관련 기능을 제공하는 Spring Security 를 각각 정리하던 중 공통적으로 중요한 키워드를 따로 정리하는 것이 좋을 것 같아서 이번 시리즈를 준비하게 됐다.
Spring MVC, Spring Secutiry 내부 동작 원리에서 가장 중요한 키워드를 각각 Servlet, Servlet Filter 라고 생각한다. 사실 서블릿을 이해한다고 해서 두 Framework를 모두 이해하게 되는 것은 당연히 아니지만, 앞서 언급한 Framework에 보다 체계적이고 논리적인 관점을 갖고 접근할 수 있게 해줄 것으로 생각한다.
지난 글에서 서블릿과 서블릿 컨테이너 각각의 역할과 두 관계에 대해서 설명했다. 이번 글에서는 보다 구체적으로, HTTP 요청이 처리되는 과정을 볼 것이다.
여러 클라이언트가 동시에 동일한 요청(예 - 좋아요 누른 포스트 리스트 조회)을 보내면 서블릿 컨테이너는 어떻게 처리할까?
웹 서비스에서 한 번 로그인(인증)을 하면 일정 기간 동안은 별도의 인증 과정 없이 인증 상태를 요구하는 API 요청을 할 수 있다. (물론, 비밀번호 등 민감한 정보를 다룰 때는 2차 인증을 요구하는 경우가 있을 수 있다.)
UX (유저 경험)면에서도 인증이 요구되는 매 요청 마다 인증을 요구하는 형식보다는 위와 같이 별도의 공간에서 유저의 인증 상태를 저장하고 이를 활용하여 일정 기간 동안은 별도의 인증이 필요 없도록 하는 방식이 유리할 것이다. 그렇다면, 서블릿 컨테이너는 유저의 상태 저장을 어떻게 할까?
HttpSession 가 특정 기간 내에서만 유효하고, 설정된 기간이 만료되면 HttpSession 객체는 소멸되어 더 이상 해당 객체에 저장된 데이터에 접근 및 활용할 수 없다. 만약 인증 대상이 저장되어 있었다면, 만료 시점 이후에는 로그인 (인증)을 다시 해야 하는 것이다. HttpSession 객체의 생성 ~ 소멸 과정을 우리는 Session Scope 로 표현할 수 있다.
Scope is used to specify the lifespan of an object. Any data stored in object in persisted throughout the scope of object and this data can be accessed any time within the scope as per requirement
이미 특정 버전 (상태)로 데이터베이스 서버가 운영 중인 상태에서 데이터베이스 이력 변경이 있는 경우 Flyway 와 같은 Database Migration 도구를 통해 관리할 수 있다. 이번 글에서는 DDL 중 ALTER , CREATE , DROP 을 활용해서 데이터베이스 마이그레이션 하는 것을 다룬다.
모든 코드는 GitHub 에서 확인할 수 있다.
Flyway 에서 제공하는 Versioned , Repeatable 마이그레이션을 각각 이용해서 테이블 생성과 테이블에 넣을 시드 데이터를 확보했다. 각각의 마이그레이션 방식을 적용하려면 파일명을 컨벤션에 맞게 설정해야 한다. 각 타입의 앞 글자를 따서 Versioned 은 V , Repeatable 은 R 로 시작한다. (이 둘의 차이 그리고 또 다른 타입의 마이그레이션 방식은 여기에서 확인할 수 있다)
Servlet Application 에서 Spring Security Framework의 동작 원리를 설명하는 글이다.
Spring Security Architecture 원문을 그대로 직역하지 않고 이해 과정을 풀어가면서 작성 했다. 일부 지엽적인 부분은 제외 했고, 제외된 부분은 별도의 토픽으로 정리할 예정이다. 글 제목에서도 언급된 것 처럼 Servlet , Servlet Container 에 대한 이해를 기반으로 읽는 것을 추천한다.
Spring Security’s Servlet support is based on Servlet
Filters, so it is helpful to look at the role ofFilters generally first. The picture below shows the typical layering of the handlers for a single HTTP request.
[ 그림 1 ]
Spring 에서 제공하는 서블릿 기반의 웹 프레젠테이션 계층 프레임워크가 Spring MVC 다.
How Spring MVC works 를 주제로 두 개의 글로 나눠서 정리할 예정이고, 첫 번째 글인 이번 글에서는 WebApplicationContext , Context Hierarchy 중심으로 스프링 애플리케이션이 웹 환경에서 스프링 컨테이너가 어떻게 구성되는 지를 다룰 예정이다.
Spring 에서는 웹 환경에서 사용하기 위해 IoC Container 중 하나인 WebApplicationContext 를 제공하면서 의도적으로 웹 애플리케이션의 컨텍스트를 두 가지로 분리했다.
Spring MVC 이름에서 알 수 있듯이 Spring MVC 웹 계층 기술은 MVC 아키텍처를 기반으로 동작한다.
MVC는 프레젠테이션 계층의 구성요소를 정보를 담은 모델 (M) , 화면 출력 로직을 담은 뷰 (V) , 그리고 제어 로직을 담은 컨트롤러 (C) 로 분리하고 이 세 가지 요소가 서로 협력해서 하나의 웹 요청을 처리하고 응답을 만들어내는 구조다. (토비의 스프링 Vol.2 - 스프링 웹 기술과 스프링 MVC)
일반적으로 MVC 아키텍처는 프론트 컨트롤러(Front controller) 패턴과 함께 사용 되는데, Spring MVC 에서는 DispatcherServlet 이 프론트 컨틀롤러 역할을 한다.
[ 그림 1 ]