过滤器，Jetty-9.2.2中的servlet的顺序 [英] Ordering of filters, servlets in Jetty-9.2.2
问题描述
我正在jetty-9.2.2.中部署CometD-3.0.1.
I am deploying CometD-3.0.1 in jetty-9.2.2.
我有自己的过滤器，我想为每个请求调用该过滤器.我已经按特定顺序在web.xml中指定了这些过滤器.
I have my own filters which I want to call for every request. I have specified those filters in the web.xml in particular order.
但是使用WebSocket，容器必须找到一种方法来处理升级请求.在Jetty中，这是通过Servlet过滤器完成的，该过滤器始终由ServletContainerInitializer作为第一个过滤器添加. 因此，在我的情况下，升级请求将永远不会到达我的过滤器，因为位于链前面的WS过滤器将在到达我的过滤器之前进行升级.
But with WebSocket, containers have to find a way to handle the upgrade request. In Jetty, this is done by a servlet filter that is always added as first filter by a ServletContainerInitializer. So in my case, a upgrade request will never hit my filter, because the WS filter that's in the front of the chain will do the upgrade before hitting my filter.
我应该怎么做才能使我的过滤器在Jetty的WS过滤器之前首先被调用?
What should I do so that my filters will be invoked first before the WS filters of Jetty ?
谢谢， 阿努伊
推荐答案
总之，不可能在websocket升级上运行servlet过滤器.
In short, it is impossible to run a servlet filter on a websocket upgrade.
在码头上选择由过滤器处理WebSocket升级只是我们对Servlet和WebSocket规范的特定实现.其他实现可能使用不同的技术.
The choice in jetty to have WebSocket upgrade handled by a filter is just our particular implementation of the Servlet and WebSocket specs. Other implementations might use different techniques.
对此有两点要了解.
-
如果容器已在已知的路径映射/路径规范上配置了WebSocket端点，则在所有servlet处理之前将处理到达的任何升级请求. Jetty选择通过内部过滤器执行此操作，其他实现则通过特殊处理来执行此操作，然后再将其处理到servlet链中.
If the container had configured WebSocket endpoints on known path mappings / path specs, then any upgrade request that arrives is handled BEFORE all servlet processing. Jetty chose to do this via an internal filter, other implementations do this with special processing before handling it off to the servlet chain.
Servlet在Servlet规范的早期不建议对Websocket升级进行过滤，因为大多数过滤器可以进行的任何更改都会导致Websocket升级出现问题.简短地讨论了拒绝某些已知会引起问题的代码路径(例如访问请求内容或响应内容，在请求或响应中设置标头等).但是事实证明，这太具有侵入性，因此声明将其声明为不可能并且不鼓励.
Servlet Filtering of websocket upgrades was discouraged early on in the servlet spec as most any changes a filter can do will cause problems to a websocket upgrade. There was brief talk about rejecting some code paths that were known to cause problems (like accessing the request content or response content, setting headers in the request or response, etc..) But this proved to be too invasive, so it was declared to be not possible and discouraged.
现在，您应该知道，如果没有发生websocket升级，并且没有错误，那么servlet处理链就会启动该请求.
Now, you should know that if the websocket upgrade doesn't occur, and without an error, then the servlet processing chain does kick in for that request.
这里的一个典型问题是，有些人围绕过滤器建立了安全性，这对Servlet有益，但对WebSockets不利.
A typical problem here is that some folks have built their security around filters, this is good for Servlets, but not WebSockets.
如果是这种情况，那么您还需要做一些工作.
If this is the case, then you have some work ahead of you.
选择以下内容:
- Split out the security logic into a standalone class that your Servlet Filters and your custom javax.websocket.server.ServerEndpointConfig.Configurator can use.
或
- 使用容器的安全层(通常在处理websocket或servlet之前发生)来增强安全性
这篇关于过滤器，Jetty-9.2.2中的servlet的顺序的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
