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

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

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

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

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

Спасибо, Ануж


person Anuj Khandelwal    schedule 09.09.2014    source источник
comment
У кого-нибудь была возможность взглянуть на это?   -  person Anuj Khandelwal    schedule 09.09.2014


Ответы (1)


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

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

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

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

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

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

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

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

Выберите из следующего:

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

or

  • Реализуйте свою безопасность, используя уровни безопасности контейнера (это всегда происходит перед любой обработкой веб-сокетов или сервлетов).
person Joakim Erdfelt    schedule 09.09.2014
comment
Спасибо за подробное объяснение. Как вы упомянули, фильтрация сервлетов обновлений веб-сокетов не рекомендуется на раннем этапе спецификации сервлета. Можете ли вы указать мне спецификацию или ссылку, где обсуждается этот вопрос? - person Anuj Khandelwal; 12.09.2014
comment
В моем случае я использую CometD и развертываю его на причале... Как вы упомянули, что реализуете безопасность, используя уровни безопасности контейнера..... что такое уровни безопасности, я не понял?.... Сказав это, все, что я хочу, это использовать учетные данные kerberos с веб-сокетом. Как мне передать учетные данные Kerberos с запросом? - person Anuj Khandelwal; 15.09.2014
comment
Если вы используете javascript в браузере, с существующим Javascript WebSocket API нет известного способа передать эти учетные данные. (мы едва можем передать BASIC-аутентификацию в URL/URI с помощью этого API) - person Joakim Erdfelt; 15.09.2014
comment
› мы едва можем передать БАЗОВУЮ аутентификацию в URL/URI с помощью этого API..... Не могли бы вы рассказать мне, как передать основные заголовки аутентификации в URL-адресе? и ТАКЖЕ, как вы упомянули в ответе: реализовать безопасность, используя уровни безопасности контейнера..... Как мне реализовать безопасность, используя уровни безопасности контейнера?. - person Anuj Khandelwal; 15.09.2014
comment
ws://{пользователь}:{пароль}@{хост}/{путь} - person Joakim Erdfelt; 15.09.2014
comment
Как вы упомянули в первом обходном пути: я попробовал первый вариант, передав заголовки аутентификации в modifyHandshake(). но я получил ava.lang.ClassCastException: org.eclipse.jetty.websocket.jsr356.server.JsrHandshakeRequest не может быть приведен к javax.servlet.http.HttpServletRequest..... Как мне установить заголовок для этого запроса? Не могли бы вы подробнее рассказать о том, как это можно сделать? - person Anuj Khandelwal; 22.09.2014