17.8. 필터 구성
필터를 사용하면 요청의 일부 측면을 수정할 수 있으며 서술자를 사용하여 필터 실행 시기를 제어할 수 있습니다. 필터의 몇 가지 일반적인 사용 사례에는 헤더 설정 또는 GZIP 압축이 포함됩니다.
필터는 JBoss EAP 6에서 사용된 전역 값과 기능적으로 동일합니다.
다음 유형의 필터를 정의할 수 있습니다.
- custom-filter
- error-page
- expression-filter
- gzip
- MOD-cluster
- request-limit
- response-header
- 재작성
다음 예제에서는 관리 CLI를 사용하여 필터를 구성하는 방법을 보여줍니다. Configuration → Subsystems → Web (Undertow) → Filters 로 이동하여 관리 콘솔을 사용하여 필터를 구성할 수도 있습니다.
기존 필터 업데이트
기존 필터를 업데이트하려면 다음을 수행합니다.
/subsystem=undertow/configuration=filter/response-header=myHeader:write-attribute(name=header-value,value="JBoss-EAP")
reload
새 필터 생성
새 필터를 생성하려면 다음을 수행합니다.
/subsystem=undertow/configuration=filter/response-header=new-response-header:add(header-name=new-response-header,header-value="My Value")
필터 삭제
필터를 삭제하려면 다음을 수행합니다.
/subsystem=undertow/configuration=filter/response-header=new-response-header:remove
reload
필터 구성에 사용할 수 있는 속성의 전체 목록은 Undertow 하위 시스템 속성 섹션을 참조하십시오.
17.8.1. buffer-request Handler 구성
클라이언트 또는 브라우저의 요청은 헤더와 본문의 두 부분으로 구성됩니다. 일반적인 경우에는 헤더와 본문이 서로 지연되지 않고 JBoss EAP로 전송됩니다. 그러나 헤더가 먼저 전송되고 몇 초 후에 본문이 전송되면 전체 요청을 보내는 지연이 있습니다. 이 시나리오에서는 JBoss EAP에 전체 요청을 실행하기 위해 대기
중으로 표시되는 스레드를 생성합니다.
헤더 전송에 따른 지연과 요청 본문은 buffer-request
핸들러를 사용하여 수정할 수 있습니다. buffer-request
핸들러는 작업자 스레드에 할당하기 전에 차단되지 않은 IO 스레드에서 요청을 사용하려고 합니다. buffer-request
핸들러가 추가되지 않으면 작업자 스레드에 스레드 할당이 직접 수행됩니다. 그러나 buffer-request
핸들러가 추가되면 핸들러는 작업자 스레드에 할당하기 전에 IO 스레드를 사용하여 차단되지 않는 방식으로 버퍼할 수 있는 데이터 양을 읽습니다.
다음 관리 CLI 명령을 사용하여 buffer-request
핸들러를 구성할 수 있습니다.
/subsystem=undertow/configuration=filter/expression-filter=buf:add(expression="buffer-request(buffers=1)") /subsystem=undertow/server=default-server/host=default-host/filter-ref=buf:add
처리할 수 있는 버퍼 요청 크기에 제한이 있습니다. 이 제한은 아래 식과 같이 버퍼 크기와 총 버퍼 수의 조합으로 결정됩니다.
total_size = num_buffers buffer_size
위의 식에서 다음을 수행합니다.
-
Total_size
는 요청이 작업자 스레드로 디스패치되기 전에 버퍼링되는 데이터 크기입니다. -
num_buffers
는 버퍼 수입니다. 버퍼 수는 핸들러의buffers
매개 변수로 설정합니다. -
buffer_size
는 각 버퍼의 크기입니다. 버퍼 크기는 theio
하위 시스템에서 설정되며 요청당 기본적으로 16KB입니다.
버퍼가 많은 요청을 구성하지 않거나 메모리가 부족할 수 있습니다.
17.8.2. SameSite
특성 구성
동일한 사이트 내에서 쿠키 액세스 여부에 관계없이 SameSite
특성을 사용하여 쿠키의 접근성을 정의합니다. 이 속성은 브라우저가 교차 사이트 요청으로 쿠키를 보내지 않기 때문에 사이트 간 위조 공격을 방지합니다.
undertow
하위 시스템에서 SameSite
CookieHandler를 사용하여 쿠키의 SameSite
속성을 구성할 수 있습니다. 이 구성을 사용하면 애플리케이션 코드를 변경할 필요가 없습니다.
다음 표에는 SameSiteCookieHandler
매개변수 세부 정보가 포함되어 있습니다.
표 17.4. SameSiteCookieHandler 매개변수
매개변수 이름 | presence | 설명 |
---|---|---|
| 선택 사항 |
이 매개 변수는 |
| 선택 사항 |
이 매개변수는 |
| 선택 사항 |
이 매개변수는 쿠키 이름에 대한 regex 패턴을 허용합니다. 이 매개변수를 지정하지 않으면 |
| 선택 사항 |
이 매개변수는 클라이언트 애플리케이션이
이 기본값을 사용하고
호환되지 않는 클라이언트 문제를 방지하기 위해 이 매개변수는 |
| 필수 |
이 매개 변수는
교차 사이트 요청 위조 공격에 대한 보안을 개선하기 위해 일부 브라우저에서는 기본 |
SameSiteCookieHandler
는 쿠키 패턴과 일치하는 쿠키 또는
> 속성을 추가합니다. cookie
-pattern
이 지정되지 않은 경우 모든 쿠키에 SameSite= <specified-modeSameSite= <specified-mode
> 속성에는 < specified-mode>인 사용자 대체 변수가 포함되어 있습니다
. cookie-pattern
은 대소문자를 구분합니다
.
브라우저에 대해 SameSite
속성을 구성하기 전에 다음 사항을 고려하십시오.
-
애플리케이션에 따라
SameSite
속성이 필요한지 여부를 확인하고 해당 쿠키를 보호해야 하는지 확인합니다. -
모든 쿠키에서
SameSite
특성 모드를None
으로 설정하면 애플리케이션이 공격에 더 취약합니다.
expression-filter를 사용하여 SameSiteCookieHandler를 구성하는 절차
expression-filter
를 사용하여 서버에서 SameSiteCookieHandler
를 구성하려면 다음 단계를 수행합니다.
다음 명령을 사용하여
SameSiteCookieHandler
를 사용하여 새표현식-filter
를 만듭니다./subsystem=undertow/configuration=filter/expression-filter=addSameSiteLax:add(expression="path-prefix('/mypathprefix') -> samesite-cookie(Lax)")
다음 명령을 사용하여
undertow
웹 서버에서expression-filter
를 활성화합니다./subsystem=undertow/server=default-server/host=default-host/filter-ref=addSameSiteLax:add
구성 파일을 추가하여 SameSiteCookieHandler를 구성하는 절차
undertow-handlers.conf
파일을 추가하여 애플리케이션에 SameSiteCookieHandler
를 구성하려면 다음 단계를 수행합니다.
-
WAR의 article-INF 디렉터리에
undertow-handlers.conf
파일을 추가합니다. undertow-handlers.conf
파일에서 특정SameSiteCookieHandler
매개변수를 사용하여 다음 명령을 추가합니다.samesite-cookie(mode=<mode>)
mode
매개변수의 유효한 값은Strict
,Lax
또는None
입니다. 위의 명령을 사용하면cookie-pattern
,case-sensitive
,enable-client-checker
또는add-secure-for-none
과 같은 다른SameSiteCookieHandler
매개변수를 구성할 수도 있습니다.