[Spring Security] OncePerRequestFilter.shouldNotFilter 메서드 효율적으로 오버라이딩 하기

이달 초부터 지인 3분과 함께 스프링 토이 프로젝트를 진행하고 있다.

GitHub - Tiketeer/Tiketeer-BE

해당 프로젝트에서는 엔드포인트 보호 작업을 위해 Spring Security와 JWT를 이용 중인데, 이를 위해 Spring Security의 OncePerRequestFilter를 구현하는 JwtAuthFilter를 아래처럼 따로 작성해준 뒤 필터 체인에 추가해주었다.

@Component
public class JwtAuthenticationFilter extends OncePerRequestFilter {
	@Override
	protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response,
		FilterChain filterChain) throws ServletException, IOException {
		try {
			// Cookie 내 jwt 추출 + verify + authentication 생성
			SecurityContextHolder.getContext().setAuthentication(authentication);
			filterChain.doFilter(request, response);
		} catch (JwtException ex) {
			// 검증 실패 시 로직
		}
	}
	@Override
	protected boolean shouldNotFilter(HttpServletRequest request) {
		// 필터를 적용하지 않을 케이스에 대해 적용 여부를 true or false로 반환
	}
}

 

문제 상황

문제는 전체 요청 흐름(서블릿 + 필터 + 컨트롤러 ~)을 테스트하는 e2e 테스트를 작성하는 와중에 발생하였다. 

위 프로젝트에는 GET /ticketings/{ticketingId} EP가 존재하는데, 해당 EP의 요구사항은 로그인을 하지 않은 사용자도 호출할 수 있어야 한다는 것이었다. 따라서 위의 shouldNotFilter 메서드에서는 해당 EP에 대한 호출에 대해 true를 반환해야 한다. 하지만 작성해둔 메서드는 그렇게 동작하지 않았다.

해당 메서드의 초안은 아래와 같다. (이해를 돕기 위해 조금 재구성하여 실제 소스코드와는 다를 수 있음)

@Override
protected boolean shouldNotFilter(HttpServletRequest request) {
	String path = request.getRequestURI();
	return getAllPublicPaths.contains(path);
}

private List<String> getAllPublicPaths() {
	return List.of(
    	// 인증을 생략할 다른 EP들 포함
        "/ticketings/*"
    );
}

자바의 List.contains 메서드는 결국 List를 순회하며 equals 통해 참 거짓 판정을 하기 때문에, 사실 위처럼 작성된 코드는 의도와 전혀 맞지 않는 완전히 잘못된 코드로 볼 수 있다. (이건 사실 Spring Security 쪽에서 사용하는 구성 클래스의 RequestMatcher에서 사용하는 Ant 패턴 개념을 착각하여 가져온 실수이다.)

 

수정 방안 1

이런 상황에서 제일 먼저 떠올릴 수 있는 방안은 결국 정규표현식이다.

이를 통하면 위의 shouldNotFilter 메서드는 아래처럼 작성될 수 있다.

@Override
protected boolean shouldNotFilter(HttpServletRequest request) {
	String path = request.getRequestURI();
	return getAllPublicPathRegexs.stream().anyMatch(regex -> 
			Pattern.compile(regex).matcher(input).matches()
	);
}

private List<String> getAllPublicPathRegexs() {
	return List.of(
    	// 인증을 생략할 다른 EP들의 정규식 포함
        "/ticketings/([\\w-]+)$"
    );
}

다만 해당 방식을 도입하는데는 크게 두가지 문제가 있다고 생각했다.

문제 1. 유지보수의 어려움

위처럼 작성할 경우, 의도한 바대로 동작시킬 수는 있지만 유지보수가 어려워진다. 나를 포함한 팀원들은 모두 필터를 적용하지 않을 엔드포인트를 개발할 때마다 정규식을 하나씩 작성해야하기 때문에 하나의 진입장벽으로 작용할 가능성이 있으며, 물론 구글링 혹은 생성형 AI의 힘을 빌릴 수는 있겠지만 작업 효율이 잘나오지는 않을 것이다.

문제 2. SecurityFilterChain에서 관리하는 EP와의 이원화로 인한 관리포인트 증가

사실 shouldNotFilter에서 수행하려는 작업은 이미 유사한 방식으로 SecurityFilterChain을 구성하는 Configuration에 아래처럼 작성되어 있다. (간소화해서 작성)

@Bean
public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {

	http.authorizeHttpRequests(req ->
		req.requestMatchers(GET, "/ticketings/*").permitAll()
	);

	return http.build();

}

그런데 해당 부분에서는 정규식보다 조금 더 간소화된 Ant 패턴을 작성해서 넣어준다. 즉, 해당 프로젝트는 특정 엔드포인트를 인가 없이 개방하기 위해 "Ant 패턴"과 "정규식"을 각각 관리해야 하는 것이다. 이는 개발하는데 있어 무조건 실수가 발생할 수 있는 지점이고, 개발 효율성을 저해시키는 요인이 될 수 있다.

 

수정 방안 2 (채택)

두번째 수정 방안은 바로 Spring Security의 RequestMatcher를 이용하는 것이다.

앞선 문제 2를 어떻게 해결할 수 있을까 고민하다가,

FilterChain에서 EP의 인가 관리를 수행할 때 사용하는 RequestMatcher를 그냥 가져와서 쓸 수는 없나? 

라는 아이디어에서 생각해낸 방안이다.

RequestMatcher는 matches 메서드를 구현해야하는 인터페이스에 불과하기 때문에 이의 구현체 중 AntPathRequestMatcher를 살펴보자.

// AntPathRequestMatcher.matches 로직
@Override
public boolean matches(HttpServletRequest request) {
	if (this.httpMethod != null && StringUtils.hasText(request.getMethod())
			&& this.httpMethod != HttpMethod.valueOf(request.getMethod())) {
		return false;
	}
	if (this.pattern.equals(MATCH_ALL)) {
		return true;
	}
	String url = getRequestPath(request);
	return this.matcher.matches(url);
}

private String getRequestPath(HttpServletRequest request) {
	if (this.urlPathHelper != null) {
		return this.urlPathHelper.getPathWithinApplication(request);
	}
	String url = request.getServletPath();
	String pathInfo = request.getPathInfo();
	if (pathInfo != null) {
		url = StringUtils.hasLength(url) ? url + pathInfo : pathInfo;
	}
	return url;
}

RequestMatcher를 구현하기 위해 작성된 matches 로직을 살펴보면 아래로 요약이 가능하다.

1. HttpMethod 일치 여부 확인
2. pattern이 MATCH_ALL(/**) 인지 확인
3. url 획득 (servletPath + pathInfo, 이를 통해 context-path는 무시됨)
4. this.matcher에게 일치 판정 위임 (이는 최종적으로 AntPathMatcher에 위임되어 Ant 패턴을 통해 매칭 판정)

즉, 이를 통하면 FilterChain과 OncePerRequestFilter에서 모두 Ant 패턴을 통해 검증을 수행할 수 있으므로 두 곳에서 사용할 경로 정보를 한 곳에서 관리할 수 있게된다. (context-path를 신경 안써도 되는건 덤)

 

구현

구현에 앞서 녹여내야할 컨텍스트를 정리하면 아래와 같다.

1. EP의 경로는 Ant 패턴 형식으로 한 곳에서 관리
2. 프로젝트 내에서 사용하는 Role의 종류는 구매자, 판매자가 존재하고 여기에 추가적으로 로그인을 수행하지 않은 "방문자"의 개념도 존재 (방문자 < 구매자 < 판매자 순)
3. 인자로 Role을 넘겨주면 그에 대응되는 RequestMatcher 벌크를 반환해야 함
4. 이 때 경로들은 HttpMethod와 패턴으로 구분됨

그리고 이에 따라 작성한 실제 로직은 아래와 같다.

@Component
public class RequestMatcherManager {
	/**
	 * if role == null, return permitAll Path
	 */
	public RequestMatcher getRequestMatchersByMinRole(@Nullable RoleEnum minRole) {
		return new OrRequestMatcher(REQUEST_INFO_LIST.stream()
			.filter(reqInfo -> {
				if (reqInfo.minRole() == null) {
					return minRole == null;
				}
				return reqInfo.minRole().equals(minRole);
			})
			.map(reqInfo -> new AntPathRequestMatcher(reqInfo.pattern(), reqInfo.method().name()))
			.toArray(AntPathRequestMatcher[]::new));
	}

	// 길이 문제 상 일부만 작성
	private static final List<RequestInfo> REQUEST_INFO_LIST = List.of(
		// member
		new RequestInfo(GET, "/members/*/purchases", RoleEnum.BUYER),
		new RequestInfo(GET, "/members/*/sale", RoleEnum.SELLER),

		// auth
		new RequestInfo(POST, "/auth/login", null),
		new RequestInfo(POST, "/auth/refresh", null),

		// ticketing
		new RequestInfo(GET, "/ticketings", null),
		new RequestInfo(GET, "/ticketings/*", null),
		new RequestInfo(POST, "/ticketings", RoleEnum.SELLER),

		// swagger
		new RequestInfo(GET, "/v3/api-docs/**", null),
		new RequestInfo(GET, "/swagger-ui.html", null),
		new RequestInfo(GET, "/swagger-ui/**", null)
	);

	private record RequestInfo(HttpMethod method, String pattern, RoleEnum minRole) {
	}
}

 

작성된 로직에 대해 간략히 설명하면 아래와 같다.

• 퍼블릭 메서드는 반환할 경로들의 최소 Role을 받도록 했다. 방문자 개념도 존재하기 때문에 nullable로 두었다.
• 내부적으로 프라이빗 레코드인 RequestInfo를 통해 EP 인가 관리에 필요한 정보들을 담도록 했다. (메서드 - 경로 - 최소 Role)
• 그리고 개발자들이 EP를 관리하기 위한 리스트를 두고, 메서드가 호출되면 이 중 최소 권한이 동일한 원소들만을 이용하여 RequestMatcher를 구성한다.
• 이 때 여러 RequestMatcher를 하나로 묶어주는 OrRequestMatcher를 이용하여 하나의 RequestMatcher로 여러 EP의 정보를 담을 수 있도록 구현했다.

위 구현을 SecurityFilterChain 구성 메서드와 OncePerRequestFilter의 shouldNotFilter 메서드에 적용하면 각각 다음과 같다.

// SecurityConfig 구성 클래스 내 빈 등록 메서드
@Bean
public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
	// 간략화한 작성
	http.addFilterAfter(jwtAuthenticationFilter, BasicAuthenticationFilter.class)
		.authorizeHttpRequests(req ->
			req
				.requestMatchers(requestMatcherManager.getRequestMatchersByMinRole(null))
				.permitAll()
				.requestMatchers(requestMatcherManager.getRequestMatchersByMinRole(SELLER))
				.hasAnyAuthority(SELLER.name())
				.requestMatchers(requestMatcherManager.getRequestMatchersByMinRole(BUYER))
				.hasAnyAuthority(BUYER.name(), SELLER.name())
				.anyRequest().authenticated()
		);

	return http.build();
}

// OncePerRequestFilter를 구현한 JwtAuthFilter의 메서드
@Override
protected boolean shouldNotFilter(HttpServletRequest request) {
	// 필터를 적용하지 않을 경로를 반환해야하기 때문에 방문자 Role (null)
	return requestMatcherManager.getRequestMatchersByMinRole(null).matches(request);
}

이를 통해, GET /member/{memberId} 경로를 잘 통과시킬 뿐 아니라, 이전에는 두 관리 지점을 각각 관리했어야 했던 문제를 함께 해결할 수 있었다. 또한 이전에는 context-path를 신경써줬어야 했던 것과 달리, AntPathRequestMatcher의 내부구현 방식에 의해 이에 대한 고려도 필요없어졌다.