Заказ фильтров, сервлетов в Jetty-9.2.2

Question

Я развертываю CometD-3.0.1 в jetty-9.2.2.

У меня есть свои фильтры, которые я хочу вызвать для каждого запроса. Я указал эти фильтры в файле web.xml в определенном порядке.

Но с помощью WebSocket контейнеры должны найти способ обработки запроса на обновление. В Jetty это делается с помощью фильтра сервлетов, который всегда добавляется в качестве первого фильтра с помощью ServletContainerInitializer. Так что в моем случае запрос обновления никогда не ударит по моему фильтру, потому что фильтр WS, который находится впереди цепочки, выполнит обновление перед ударом моего фильтра.

Что мне делать, чтобы мои фильтры вызывались сначала перед фильтрами WS Jetty?

Спасибо, Anuj

Answer 1

Короче говоря, это невозможно запустить сервлет фильтр на обновления WebSocket.

Выбор в причале для обновления WebSocket, обработанного фильтром, является нашей конкретной реализацией спецификаций Servlet и WebSocket. Другие реализации могут использовать разные методы.

Theres 2 вещи, чтобы понять об этом.

1. Если контейнер был настроен WebSocket конечных точек на известных путях отображений/пути спецификации, то любой запрос обновления, который прибывает обрабатывается, прежде чем все обработки сервлет. Jetty решила сделать это через внутренний фильтр, другие реализации делают это со специальной обработкой, прежде чем обращаться с ней в цепочку сервлетов.

2. Сервлет Фильтрация обновлений websocket была отклонена на ранней стадии в спецификации сервлета, поскольку большинство изменений, которые может сделать фильтр, вызовет проблемы при обновлении веб-узла. Был краткий разговор об отказе от некоторых путей кода, которые, как известно, вызывали проблемы (например, доступ к содержимому запроса или содержимому ответа, настройка заголовков в запросе или ответе и т. Д.). Но это оказалось слишком инвазивным, поэтому было объявлено быть не может и не рекомендуется.

Теперь, вы должны знать, что если обновление WebSocket не происходит, и без ошибок, то цепочка обработки сервлета делает удар в для этого запроса.

Типичная проблема заключается в том, что некоторые люди создали свою защиту вокруг фильтров, это хорошо для сервлетов, но не для WebSockets.

Если это так, то перед вами впереди какая-то работа.

Пик из следующих:

• Сплит из логики безопасности в автономный класс, сервлет фильтры и пользовательский javax.websocket.server.ServerEndpointConfig.Configurator можно использовать.

или

• Реализовать свою безопасность, используя уровни безопасности контейнера (что всегда происходит перед любой обработкой WebSockets или сервлеты)