[SPRING] Spring MVC DelegatingFilterProxy의 요점은 무엇입니까?

Spring MVC DelegatingFilterProxy의 요점은 무엇입니까?

내 봄 MVC 애플 리케이션의 web.xml에서 이것을 참조하십시오 :

<filter>
    <filter-name>springSecurityFilterChain</filter-name>
    <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
</filter>

나는 그것이 왜 존재하고 그것이 실제로 필요한지를 알아 내기 위해 노력하고 있습니다.

나는이 설명을 Spring 문서에서 찾았지만 그것을 이해하는 데 도움이되지 않는다 :

이 컴포넌트는 web.xml에 정의 된 서블릿과 Spring applicationContext.xml에 정의 된 컴포넌트 사이의 "접착제"라고 제안하는 것으로 보인다.

그래서, 만약 내가 이것을 web.xml에서 제거한다면, 어떻게 될 것인가? 내 서블릿이 Spring 컨테이너와 통신 할 수 없습니까? **

해결법

1. ==============================

   1.여기에는 어떤 종류의 마법이 있습니다 만, 결국에는 모든 것이 결정론적인 프로그램입니다.

   여기에는 어떤 종류의 마법이 있습니다 만, 결국에는 모든 것이 결정론적인 프로그램입니다.

   DelegatingFilterProxy는 앞서 설명한 것처럼 "Filter 인터페이스를 구현하는 Spring 관리 빈에 위임하는", 즉 Spring 애플리케이션에서 빈 ( "대상 빈"또는 "위임자")을 찾는 것을 목표로하는 필터입니다. 컨텍스트를 생성하고 호출합니다. 그게 어떻게 가능해? 이 Bean은 javax.servlet.Filter를 구현하므로 doFilter 메소드가 호출됩니다.

   어떤 콩이 호출됩니까? DelegatingFilterProxy ""targetBeanName "[...]을 지원하여 Spring 응용 프로그램 컨텍스트에서 대상 bean의 이름을 지정합니다."

   web.xml에서 bean 이름이 "springSecurityFilterChain"임을 알았습니다.

   따라서 웹 응용 프로그램의 컨텍스트에서 필터는 응용 프로그램 컨텍스트에서 "springSecurityFilterChain"이라는 bean을 인스턴스화 한 다음 doFilter () 메서드를 통해 위임합니다.

   응용 프로그램 컨텍스트는 모든 APPLICATION-CONTEXT (XML) 파일로 정의됩니다. 예 : applicationContext.xml 및 applicationContext-security.xml

   그래서 후자에서 "springSecurityFilterChain"이라는 이름의 콩을 찾으십시오.

   ... 아마도 당신은 할 수 없습니다 (예를 들어 자습서를 따라 갔거나 Roo를 사용하여 보안을 구성한 경우)

   마법은 다음과 같습니다. 보안 구성과 같은 새로운 요소가 있습니다.

   <http auto-config="true" use-expressions="true"> 
   

   http://www.springframework.org/schema/security/spring-security-3.0.xsd에서 허용하는대로 트릭을 수행합니다.

   Spring이 XML 파일을 사용하여 응용 프로그램 컨텍스트를로드 할 때 요소를 찾으면 필터 스택과 보호 된 URL 인 HTTP 보안을 설정하고 "springSecurityFilterChain"이라는 FilterChainProxy를 등록하려고 시도합니다.

   또는 다음과 같이 고전적인 방식으로 Bean을 정의 할 수 있습니다.

   <beans:bean id="springSecurityFilterChain" class="org.springframework.security.web.FilterChainProxy">
   

   그러나 구성을 많이해야하기 때문에 권장하지 않습니다 (사용하려는 모든 필터 및 그 중 12 개가 넘습니다)

2. ==============================

   2.Servlet Filter가 무엇이고 어떻게 작동하는지 알고 있습니까? 이것은 Servlet Spec의 매우 유용한 부분으로, AOP와 유사한 개념을 HTTP 요청 서비스에 적용 할 수있게 해줍니다. 많은 프레임 워크는 다양한 일에 대해 Filter 구현을 사용하며, 작성하기가 매우 쉽고 유용하기 때문에 맞춤 구현을 찾는 경우가 드뭅니다. Spring 애플리케이션에서, 앱이 할 수있는 대부분의 것들이 Spring 빈에있다. 하지만 Filter 인스턴스는 서블릿 컨테이너에 의해 제어됩니다. 컨테이너는 인스턴스화, 초기화 및 파기합니다. 서블릿 스펙은 어떤 종류의 스프링 통합도 필요로하지 않으므로 Spring 애플 리케이션과 작업을 수행하는 빈에 연결하는 편리한 방법이없는 정말 유용한 개념 (필터)이 남아있다.

   Servlet Filter가 무엇이고 어떻게 작동하는지 알고 있습니까? 이것은 Servlet Spec의 매우 유용한 부분으로, AOP와 유사한 개념을 HTTP 요청 서비스에 적용 할 수있게 해줍니다. 많은 프레임 워크는 다양한 일에 대해 Filter 구현을 사용하며, 작성하기가 매우 쉽고 유용하기 때문에 맞춤 구현을 찾는 경우가 드뭅니다. Spring 애플리케이션에서, 앱이 할 수있는 대부분의 것들이 Spring 빈에있다. 하지만 Filter 인스턴스는 서블릿 컨테이너에 의해 제어됩니다. 컨테이너는 인스턴스화, 초기화 및 파기합니다. 서블릿 스펙은 어떤 종류의 스프링 통합도 필요로하지 않으므로 Spring 애플 리케이션과 작업을 수행하는 빈에 연결하는 편리한 방법이없는 정말 유용한 개념 (필터)이 남아있다.

   DelegatingFilterProxy를 입력하십시오. 필터 구현을 작성하여 Spring 빈으로 만들지 만, 자신의 Filter 클래스를 web.xml에 추가하는 대신 DelegatingFilterProxy를 사용하고 Spring 컨텍스트에서 필터의 빈 이름을 지정한다. (명시 적으로 이름을 제공하지 않으면 "filter-name"을 사용합니다.) 그런 다음 런타임에 DelegatingFilterProxy는 실제 구현 (Spring에서 작성 및 구성한 요청)을 찾는 복잡성을 처리하고 요청을 요청에 라우팅합니다 . 따라서 런타임시에는 web.xml에 필터를 나열한 것처럼 보이지만 다른 Spring bean처럼 연결할 수있는 이점이 있습니다.

   web.xml에서 해당 필터 매핑을 제거하면 모든 작업이 계속되지만 아무 URL도 보안되지 않습니다. (이것은 "springSecurityFilterChain"이라는 이름이 정확히 무엇을 설명하는지 가정하고 있습니다.)이 매핑은 들어오는 모든 요청을 필터링하여 스프링 컨텍스트에 정의 된 보안 필터로 전달하기 때문입니다.

3. ==============================

   3.서블릿 필터는 일반적으로 Java WebApp 개념입니다. 애플리케이션에서 Spring 프레임 워크를 사용하는지 여부에 관계없이 모든 웹 애플리케이션에서 서블릿 필터를 사용할 수 있습니다.

   서블릿 필터는 일반적으로 Java WebApp 개념입니다. 애플리케이션에서 Spring 프레임 워크를 사용하는지 여부에 관계없이 모든 웹 애플리케이션에서 서블릿 필터를 사용할 수 있습니다.

   이러한 필터는 요청이 대상 서블릿에 도달하기 전에 요청을 가로 챌 수 있습니다. 서블릿 필터에 권한과 같은 공통 기능을 구현할 수 있습니다. 구현 된 후에는 web.xml의 필터를 특정 서블릿, 특정 요청 URL 패턴 또는 모든 URL 패턴에 적용되도록 구성 할 수 있습니다.

   최신 웹 응용 프로그램에는 이러한 필터가 수십 가지 있습니다. 인증, 캐싱, ORM 세션 관리 및 종속성 주입과 같은 것들은 서블릿 필터를 사용하여 구현되는 경우가 많습니다. 이 모든 필터는 web.xml에 등록해야합니다.

   서블릿 컨테이너는 web.xml에 선언 된 필터의 인스턴스를 만들고 적절한 시간 (즉, 서블릿 요청을 처리 할 때)에 호출합니다. 이제 대부분의 DI (Dependency Injection) 팬과 같은 경우 인스턴스 생성은 DI 프레임 워크 (Spring)가 더 잘하는 것이라고 말할 수 있습니다. 스프링으로 만든 서블릿 필터를 얻을 수 없으므로 모든 DI 장점을 다룰 수 있습니까?

   DelegatingFilterProxy는 DelegatingFilterProxy가 위치하는 곳입니다. DelegatingFilterProxy는 Spring Framework에서 제공하는 javax.servlet.Filter 인터페이스를 구현 한 것입니다. web.xml에서 DelegatingFilterProxy를 구성하면 스프링 구성에서 필터링을 수행하는 실제 bean을 선언 할 수 있습니다. 이렇게하면 Spring은 실제 필터링을 수행하는 Bean의 인스턴스를 만들고 DI를 사용하여 이러한 Bean을 구성 할 수 있습니다.

   web.xml에는 DelegatingFilterProxy 선언이 하나만 필요하지만 애플리케이션 컨텍스트에 여러 필터링 콩을 함께 연결할 수 있습니다.

4. ==============================

   4.서블릿 필터는 스프링이 아닌 서블릿 컨테이너에 의해 관리된다. 그리고 스프링 구성 요소를 필터에 주입해야 할 수도 있습니다.

   서블릿 필터는 스프링이 아닌 서블릿 컨테이너에 의해 관리된다. 그리고 스프링 구성 요소를 필터에 주입해야 할 수도 있습니다.

   그래서, 다음과 같은 것이 필요할 경우 :

   public class FooFilter {
   
       @Inject
       private FooService service;
   
       public void doFilter(....) { .. }
   
   }
   

   위임 필터 프록시가 필요합니다.

5. ==============================

   5.당신은 '접착제'물건에 대한 권리입니다. FilterChainProxy의 JavaDocs에서 작성한 것처럼 :

   당신은 '접착제'물건에 대한 권리입니다. FilterChainProxy의 JavaDocs에서 작성한 것처럼 :

   훌륭한 설명은 Spring Security Namespace 뒷부분의 blog의 FIlterChainProxy 섹션을 참조하십시오.

6. ==============================

   6.나는 web.xml의 "springSecurityFilterChain"에 당혹 스러웠고 springframework 보안 문서에서이 대답을 발견했다.

   나는 web.xml의 "springSecurityFilterChain"에 당혹 스러웠고 springframework 보안 문서에서이 대답을 발견했다.

   다음은 http://docs.spring.io/spring-security/site/docs/3.0.x/reference/appendix-namespace.html 링크입니다.

7. ==============================

   7.오랜 시간이 걸렸지 만 같은 질문을 한 적이 있습니다. https://www.javacodegeeks.com/2013/11/spring-security-behind-the-scenes.html

   오랜 시간이 걸렸지 만 같은 질문을 한 적이 있습니다. https://www.javacodegeeks.com/2013/11/spring-security-behind-the-scenes.html

   문제의 필터를 제거하고 추가하여 봄 보안 프로젝트를 실행하려고했습니다. 필터를 추가하면 호출은 봄 보안 구성에 정의 된대로 필요한 로그인 페이지로 리디렉션됩니다.

   따라서 @ 라이언의 대답에 동의합니다.

from https://stackoverflow.com/questions/6725234/whats-the-point-of-spring-mvcs-delegatingfilterproxy by cc-by-sa and MIT license