Pedido de filtros, servlets en Jetty-9.2.2

cometd

Question

Estoy implementando CometD-3.0.1 en jetty-9.2.2.

Tengo mis propios filtros que deseo llamar para cada solicitud. He especificado esos filtros en el web.xml en un orden particular.

Pero con WebSocket, los contenedores tienen que encontrar una manera de manejar la solicitud de actualización. En Jetty, esto se hace mediante un filtro de servlet que siempre se agrega como primer filtro mediante un ServletContainerInitializer. Entonces, en mi caso, una solicitud de actualización nunca llegará a mi filtro, porque el filtro WS que está al frente de la cadena hará la actualización antes de presionar mi filtro.

¿Qué debo hacer para que mis filtros se invoquen primero antes de los filtros WS de Jetty?

Gracias, Anuj

Answer 1

En resumen, es imposible ejecutar un filtro de servlet en una actualización de websocket.

La elección en jetty de que la actualización de WebSocket sea manejada por un filtro es solo nuestra implementación particular de las especificaciones de Servlet y WebSocket. Otras implementaciones pueden usar diferentes técnicas.

Hay dos cosas para entender sobre esto.

1. Si el contenedor ha configurado puntos finales WebSocket en asignaciones de ruta conocidas / especificaciones de ruta, entonces cualquier solicitud de actualización que llegue se maneja ANTES de todo el procesamiento de servlets. Jetty eligió hacer esto a través de un filtro interno, otras implementaciones lo hacen con un procesamiento especial antes de manejarlo a la cadena de servlets.

2. El filtrado de servlets de las actualizaciones de websocket se desaconsejó desde el principio en la especificación del servlet, ya que la mayoría de los cambios que puede hacer un filtro causarán problemas a una actualización de websocket. Hubo una breve charla sobre el rechazo de algunas rutas de código que causaban problemas (como acceder al contenido de la solicitud o de respuesta, establecer encabezados en la solicitud o respuesta, etc.). Pero esto resultó ser demasiado invasivo, por lo que se declaró no ser posible y desalentado.

Ahora, debe saber que si la actualización de websocket no ocurre, y sin un error, la cadena de procesamiento de servlets se activa para esa solicitud.

Un problema típico aquí es que algunas personas han construido su seguridad en torno a los filtros, esto es bueno para Servlets, pero no para WebSockets.

Si este es el caso, entonces tienes algo de trabajo por delante.

Selección de lo siguiente:

• Divida la lógica de seguridad en una clase independiente que sus Filtros de Servlets y su javax.websocket.server.ServerEndpointConfig.Configurator personalizado puedan usar.

o

• Implemente su seguridad utilizando las capas de seguridad del contenedor (eso siempre ocurre antes de cualquier procesamiento de websockets o servlets)