본문으로 바로가기
반응형



첫 화면에서 로그인을 해야 기능을 사용할 수 있는 어떤 웹 사이트를 가정해보자.

일반적으로 첫 화면에서 로그인을 하고, 나머지 기능들을 ui 클릭을 통해 사용할 것이다.


하지만, 어떤 사용자가 로그인을 해야만 하는 어떤 기능의 url을 복사해 뒀다가 로그인 없이 주소창에 그 url을 붙여넣는다면 어떨까?


'별도의 처리' 가 없다면 아마 로그인 없이도 기능을 사용하게 되거나, 에러가 발생할 것이다.


그 '별도의 처리'가 포함된 로직은 일반적으로 아래와 같을 것이다.


1. 사용자는 로그인을 한다. 

2. 시스템은 로그인한 사용자 정보를 세션에 저장한다. 

3. 사용자는 기능을 요청한다.

4. 시스템은 사용자가 요청한 기능을 수행하기 전에 요청한 사용자의 세션을 체크한다. 

5. 시스템은 올바른 세션일 경우 기능 승인, 세션이 없거나 올바르지 않을 경우 사용자를 로그인 페이지로 이동시킨다.


그렇다면 이 중 4번과 5번의 처리를 어떻게 해야할까?

Spring MVC를 사용한다면 클라이언트의 기능 사용 요청이 Controller로 들어올 테니, 각 컨트롤러마다 기능 로직을 수행하기 전 세션 체크를 해 주면 될 것이다.

1000개의 기능이 있다면 1000개의 세션 체크 로직이 들어가게 되며 이는 중복된 코드이다.


그렇다면 세션을 체크하는 로직을 하나의 유틸로 만들고, 각 컨트롤러에서 이 유틸을 한번씩 호출하면 되지 않을까? 상당히 응집도가 높아 졌지만, 아직 1000개의 컨트롤러에는 세션 체크 유틸을 호출하는 코드가 중복해서 남아있다.


이런 상황에서 사용할 수 있도록, 컨트롤러로 오는 모든(혹은 일부 조건의) 요청들을 컨트롤러가 처리하기 전에 가로채(intercept해) 로직을 끼워 넣는 기능이 존재한다.




위 로그인 예시와 같은 상황에서 프로젝트에 따라 두가지 방법이 존재한다.

1. Filter(필터)를 사용한다.

2. Interceptor(인터셉터)를 사용한다.


필터와 인터셉터의 차이는 다음 그림과 같다.


(Spring MVC request lifecycle)



위 그림을 볼 때 Filter와 Interceptor의 가장 큰 차이는 이렇다.


1. Filter는 Dispatcher servlet의 앞단에서 정보를 처리하고, Interceptor는 Dispatcher servlet에서 Handler(Controller)로 가기 전에 정보를 처리한다.

2. 또한 필터는 J2EE 표준 스펙에 정의 되어 있는 기능이며, 인터셉터의 경우는 Spring Framework에서 자체적으로 제공하는 기능이라고 한다.


정확히 어떤 상황에 어떤 기능을 사용해야 하는가에 대해서는 갑론을박이 많지만, 인코딩이나 보안 관련 처리와 같은 web app의 전역적으로 처리해야 하는 로직은 필터로 구현하고 클라이언트에서 들어오는 디테일한 처리(인증, 권한 등)에 대해서는 주로 인터셉터에서 처리하는듯 하다.


그렇다면, 위에서 예를 든 로그인 세션 인증에 관해서는 인터셉터에서 처리하는 것이 더 나을 것이다. 


(spring에서 interceptor를 사용해 구현한 로그인 세션체크 예시 : http://www.leafcats.com/40 )




반응형

 Other Contents