sirve requestmapping que para mvc funciona formulario español ejemplo dependencias conceptos como java spring spring-mvc spring-security

java - requestmapping - spring mvc español



¿Cuál es el objetivo de DelegatingFilterProxy de Spring MVC? (7)

¿Qué son los filtros Servlet?

Los filtros de servlets son, en general, un concepto de Java WebApp. Puede tener filtros de servlets en cualquier aplicación web, ya sea que utilice o no el marco Spring en su aplicación.

Estos filtros pueden interceptar solicitudes antes de que lleguen al servlet de destino. Puede implementar funcionalidades comunes, como autorización, en filtros de servlets. Una vez implementado, puede configurar el filtro en su web.xml para aplicarlo a un servlet específico, patrones de URL de solicitud específicos o todos los patrones de url.

¿Dónde se usan los filtros de servlet?

Las aplicaciones web modernas pueden tener docenas de tales filtros. Cosas como autorización, almacenamiento en caché, gestión de sesión ORM e inyección de dependencia a menudo se implementan con la ayuda del filtro de servlet. Todos estos filtros deben estar registrados en web.xml .

Crear instancias de filtros de servlets sin Spring Framework

Su contenedor de servlets crea instancias de filtros declarados en web.xml y los llama en los momentos apropiados (es decir, cuando se atienden solicitudes de servlets). Ahora bien, si usted es como la mayoría de los fanáticos de Dependency Injection (DI), probablemente diría que la creación de instancias es lo que hace mejor mi marco DI (Spring). ¿No puedo hacer que mis filtros de servlet se creen con Spring para que sean compatibles con todos los DI goodness?

DelegatingFilterProxy , para que Spring cree sus instancias de filtro

Aquí es donde DelegatingFilterProxy interviene. DelegatingFilterProxy es una impulsión de la interfaz javax.servlet.Filter proporcionada por Spring Framework. Una vez que configure DelegatingFilterProxy en web.xml, puede declarar los beans reales que hacen el filtrado en su configuración de primavera. De esta forma, Spring crea las instancias de beans que realizan el filtrado real, y puede usar DI para configurar estos beans.

Tenga en cuenta que solo necesita una sola declaración DelegatingFilterProxy en web.xml pero puede tener varios beans de filtrado encadenados en el contexto de su aplicación.

Veo esto en el web.xml mi aplicación Spring MVC:

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

Estoy tratando de descubrir por qué está ahí y si realmente es necesario.

Encontré esta explicación en los documentos de Spring pero no me ayuda a encontrarle sentido:

Parece sugerir que este componente es el "pegamento" entre los servlets definidos en web.xml y los componentes definidos en Spring applicationContext.xml .

7.1 DelegatingFilterProxy

Al usar filtros de servlets, obviamente debe declararlos en su web.xml , o serán ignorados por el contenedor de servlets. En Spring Security, las clases de filtro también son Spring beans definidas en el contexto de la aplicación y, por lo tanto, pueden aprovechar las ricas instalaciones de inyección de dependencias y las interfaces de ciclo de vida de Spring. Spring DelegatingFilterProxy proporciona el enlace entre web.xml y el contexto de la aplicación.

Al usar DelegatingFilterProxy, verá algo como esto en el archivo web.xml :

<filter> <filter-name>myFilter</filter-name> <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class> </filter> <filter-mapping> <filter-name>myFilter</filter-name> <url-pattern>/*</url-pattern> </filter-mapping>

Tenga en cuenta que el filtro es en realidad un DelegatingFilterProxy , y no la clase que realmente implementará la lógica del filtro. Lo que DelegatingFilterProxy hace es delegar los métodos del filtro a través de un bean que se obtiene del contexto de la aplicación Spring. Esto permite que Bean se beneficie del soporte del ciclo de vida del contexto de la aplicación web Spring y de la flexibilidad de configuración. El bean debe implementar javax.servlet.Filter y debe tener el mismo nombre que en el elemento filter-name. Lea el Javadoc para DelegatingFilterProxy para más información

Entonces, si saco esto de mi web.xml , ¿qué pasará? Mis servlets no podrán comunicarse con el contenedor Spring? **


¿Sabes qué es un Filter Servlet y cómo funciona? Es una pieza muy útil de la especificación de servlets, que nos permite aplicar conceptos similares a los de AOP al servicio de las solicitudes de HTTP. Muchos marcos utilizan implementaciones de filtro para varias cosas, y no es raro encontrar implementaciones personalizadas de ellas porque son muy simples de escribir y útiles. En una aplicación de Spring, la mayoría de las cosas que su aplicación puede hacer es en sus beans de Spring. Sin embargo, una instancia de filtro está controlada por el contenedor de servlets. El contenedor lo instancia, lo inicializa y lo destruye. Sin embargo, el Servlet Spec no requiere ningún tipo de integración de Spring, por lo que le queda un concepto realmente útil (Filtros) sin una forma conveniente de vincularlo a su aplicación Spring y los beans que hacen el trabajo.

Ingrese DelegatingFilterProxy. Escribe una implementación de filtro y la convierte en un bean de primavera, pero en lugar de agregar su propia clase de filtro al web.xml, usa DelegatingFilterProxy y le da el nombre de bean de su filtro en el contexto de Spring. (Si no proporciona explícitamente un nombre, usa el "nombre-filtro"). Luego, en tiempo de ejecución, DelegatingFilterProxy maneja la complejidad de encontrar la implementación real, la que usted escribió y configuró en Spring, y las solicitudes de enrutamiento a la misma. . Por lo tanto, en tiempo de ejecución, es como si hubiera listado su filtro en el archivo web.xml, pero tiene la ventaja de poder cablearlo como cualquier otro bean de primavera.

Si elimina esa asignación de filtros de su web.xml, todo continuará funcionando, pero ninguna de sus URL estará protegida. (Eso supone que el nombre "springSecurityFilterChain" describe con precisión lo que hace). Esto se debe a que esta asignación está filtrando cada solicitud entrante y entregándola a un filtro de seguridad definido en su contexto de primavera.


Aquí hay algún tipo de magia, pero al final, todo es un programa determinista.

DelegatingFilterProxy es un filtro como se explicó anteriormente, cuyo objetivo es " delegar a un bean gestionado por Spring que implementa la interfaz de filtro ", es decir, encuentra un bean ("bean de destino" o "delegado") en su aplicación Spring contexto y lo invoca. ¿Como es posible? Como este bean implementa javax.servlet.Filter, se llama a su método doFilter.

¿Qué bean se llama? DelegatingFilterProxy "Admite un" targetBeanName "[...], especificando el nombre del bean objetivo en el contexto de la aplicación Spring".

Como viste en tu web.xml, el nombre del bean es " springSecurityFilterChain " .

Entonces, en el contexto de una aplicación web, un filtro crea una instancia de un bean llamado "springSecurityFilterChain" en el contexto de su aplicación y luego lo delega a través del método doFilter ().

Recuerde, el contexto de su aplicación se define con TODOS LOS archivos CONTEXTO DE APLICACIÓN (XML). Por ejemplo: applicationContext.xml AND applicationContext-security.xml.

Intenta encontrar un bean llamado "springSecurityFilterChain" en este último ...

... y probablemente no pueda (por ejemplo, si siguió un tutorial o si configuró la seguridad con Roo)

Aquí está la magia: hay un nuevo elemento para configurar la seguridad , algo así como

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

como está permitido por http://www.springframework.org/schema/security/spring-security-3.0.xsd , hará el truco.

Cuando Spring carga el contexto de la aplicación usando archivos XML, si encuentra un elemento, intentará configurar la seguridad HTTP, es decir, una pila de filtro y URL protegidas y registrar FilterChainProxy llamado "springSecurityFilterChain".

Alternativamente, puede definir el bean de la manera clásica, es decir:

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

Pero es menos recomendable, ya que necesita una gran cantidad de configuración (todos los filtros que va a utilizar. Y hay más de una docena de ellos)


El caso es que los filtros de servlet son administrados por el contenedor de servlets y no por la primavera. Y es posible que necesite inyectar algunos componentes de resorte en sus filtros.

Entonces, si necesitas algo como:

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

entonces necesitas el proxy de filtro delegante.


Ha pasado mucho tiempo pero tuve la misma pregunta y encontré esto: https://www.javacodegeeks.com/2013/11/spring-security-behind-the-scenes.html

Traté de ejecutar mi proyecto de seguridad de primavera eliminando el filtro en cuestión y también agregándolo. Lo que encontré es que si agregamos el filtro, solo entonces la llamada se redirigirá a la página de inicio de sesión requerida como se define en la configuración de seguridad de primavera.

Por lo tanto, aceptando la respuesta de @ Ryan.


Me quedé perplejo con "springSecurityFilterChain" en web.xml y encontré esta respuesta en el documento de seguridad de Springframework:

El elemento <http> encapsula la configuración de seguridad para la capa web de su aplicación. > Crea un bean FilterChainProxy llamado "springSecurityFilterChain" que mantiene la pila de filtros de seguridad que conforman la configuración de seguridad web [19]. Algunos filtros centrales siempre> se crean y otros se agregarán a la pila dependiendo de los atributos secundarios elementos> presentes. Las posiciones de los filtros estándar son fijas (consulte la tabla de orden de filtro en> introducción del espacio de nombres), eliminando una fuente común de errores con versiones anteriores del marco> cuando los usuarios tenían que configurar la cadena de filtros explícitamente en el beanFilterChainProxy. Por supuesto, puede hacer esto si necesita un control total de la configuración.

Aquí está el enlace http://docs.spring.io/spring-security/site/docs/3.0.x/reference/appendix-namespace.html


Tienes razón sobre cosas de "pegamento". Como está escrito en JavaDocs de FilterChainProxy :

FilterChainProxy está vinculado a la cadena de filtros del contenedor de servlets al agregar una declaración Spring DelegatingFilterProxy estándar en el archivo web.xml de la aplicación.

Consulte la sección FIlterChainProxy del blog Behind the Spring Security Namespace para obtener una explicación excelente.