PlayFramework Filter 적용하기

서론

스프링에서는 들어오는 요청에 대해 사전에 제어 할 수 있는 Filter와 Interceptor가 존재한다. 스프링의 Filter와 Interceptor는 요청에 대해 사전 처리, 후처리를 할 수 있는 기능이다. 기능은 똑같지만 서로 다른 차이가 있다. 간단하게 설명하자면 Filter와 Interceptor는 처리 시점이 다르다 Filter의 경우 Servlet으로 호출이 들어가기 전 해당 호출을 처리하며 Interceptor의 경우 Servlet을 통과해온 요청이 Controller로 들어가기 전에 대한 호출을 처리하는 것의 차이를 들 수 있다. 

Play에서도 Filter를 지원하는데 어떻게 사용하는지에 대해서 알아보자. 이 포스팅을 작성하면서 사용한 Play Version은 2.4.2, Scala Version은 2.11이다.

Filter Class의 작성

우선 요청에 대해 Filter를 할 수 있는 Class를 작성을 해보자. Filter를 구현하기 위해서는 Filter Trait를 구현해야한다. Filter Trait를 상속 받게 되면 apply 메소드를 구현해야하는데 두개의 매개변수로 된 커링함수이다.

첫 번째 매개변수인 (nextFilter: (RequestHeader) => Future[Result]의 경우 RequestHeader를 받아 결과를 생성하는 함수이며 요청을 다음 Filter로 넘겨주는 역할을 하는 함수이다.
두 번째 매개변수의 경우 실제 요청의 ReqeustHeader를 받는 부분이며 nextFilter에서 해당 매개변수의 값을 가공하게 된다. 

아래는 요청에 대해 처리 시간을 로그로 남기고 Response header에 응답 시간을 붙여서 전달하는 Filter이다.

이와 같은 처리가 가능 한 것이 Play Filter의 특징 때문이다. 특징에 대해서는 마지막 부분 로그를 보면서 설명한다.

package interceptors import play.api.Logger import play.api.mvc.{Filter, RequestHeader, Result} import scala.concurrent.Future //global import가 없으면 에러발생 import scala.concurrent.ExecutionContext.Implicits.global class LoggingFilter extends Filter{ override def apply(nextFilter: (RequestHeader) => Future[Result])(requestHeader: RequestHeader): Future[Result] = { val startTime = System.currentTimeMillis println("LoggingFilter : " + startTime) nextFilter(requestHeader).map{result => val endTime = System.currentTimeMillis val requestTime = endTime - startTime println("LoggingFilter : " + endTime) val testStr = requestHeader.getQueryString("abs") println(testStr.getOrElse()) Logger.info(s"${requestHeader.method} ${requestHeader.uri} " + s"took ${requestTime}ms and returned ${result.header.status}") result.withHeaders("Request-Time" -> requestTime.toString) } } }

위의 scala.concurrent.ExecutionContext.Implicits.global을 import 해주지 않으면 에러가 발생 하므로 꼭 import를 해주어야 한다.

구현한 Filter Class를 HttpFilters에 등록하기

위에서 작성한 Filter Class만 있다고 해서 Filter가 적용되는 것은 아니다. 구현한 Filter를 HttpFilters를 구현 클래스에 등록을 해주어야 요청에 대해서 동작하게 된다. HttpFilters trait를 상속하면 filters라는 메소드를 구현해야하고 해당 메소드를 구현하면서 Filter들을 등록하게 된다.

여기에 등록되는 순서대로 FilterChain을 생성하게 된다.

package interceptors import javax.inject.Inject import play.api.http.HttpFilters class MyFilters @Inject()(log1: LoggingFilter, log2: LoggingFilter2) extends HttpFilters{ val filters = Seq(log1, log2) }

위 처럼 Seq안에 (log1, log2)로 생성하게 되면 FilterChain이 log1 -> log2 순서로 흘러가게 된다.

HttpFilters구현체 application에 등록

위의 두가지를 하고 난 뒤에 마지막으로 해야 할 것은 Play Framework에서 해당 필터를 인식 할 수 있도록 설정해주는 일이다. Filter에 관련된 구현체들이 Project의 Root파일에 존재한다면 이 설정이 필요하지 않지만 보통의 프로젝트는 패키지 단위로 클래스 파일을 만들기 때문에 이 설정은 필수적일 거라고 생각한다. 여기서 말한 Project의 Root파일은 intelij의 기준으로 app 파일을 말한다.

설정은 conf/application.conf파일에 하게 된다.

play.http.filters=interceptors.MyFilters

다음과 같은 설정을 추가해주면 되는데 HttpFilters를 구현한 클래스의 위치를 명시해주면 동작하게 된다.

실행 결과

[info] p.a.l.c.ActorSystemProvider - Shutdown application default Akka system: application [warn] application - Logger configuration in conf files is deprecated and has no effect. Use a logback configuration file instead. [info] p.a.l.c.ActorSystemProvider - Starting application default Akka system: application [info] play.api.Play - Application started (Dev) LoggingFilter Start LoggingFilter2 Start ShowMethod : 1487379286370 LoggingFilter2 End LoggingFilter End

여기서 LoggingFilter2는 구현한 내용을 포스팅 하지 않았다.

결과를 보게 되면 페이지의 호출이 되면 LoggingFilter Start가 동작하고 FilterChain의 두번째 순서에 있는 LoggingFilter2에 의해 LoggingFilter2 Start가 동작하게 된다. 그 뒤에 Controller의 ShowMethod의 호출이 진행된 것을 확인 할 수 있다.

그 다음은 호출된 순서의 반대로 Filter의 호출이 진행되게 된다.