I am using Cometd 3.0.1 with jetty 9.2.3 using JSR 356 based websocket implementation (and not jetty's own websocket implementation).
I have added some auth filters which basically ask for authentication headers from request. But as websocket upgrade happen as a part of websocketupgrade filter, is there a way to make authentication work here?
Authenticating via a Filter is the wrong way to accomplish authentication.
Correct Solution:
The servlet spec expects you to setup and configure the the authentication and authorization layers of your application using the servlet techniques of both the container and the application metadata (WEB-INF/web.xml
)
This means you setup a the container side security, either using the Jetty container specific LoginService
, or using a JAAS spec configuration. Then you reference your security realms in your WEB-INF/web.xml
and use them. If you have something custom, then you can hook into the LoginService
of your choice (even a custom one) and manage it accordingly.
JAAS and LoginService Authentication and Authorization is applied before all filters and servlets.
In this scenario, you'll have access to the authentication information during the upgrade process, in particular during the ServerEndpointConfig.Configurator.modifyHandshake()
Ugly Hack Solution:
Add the org.eclipse.jetty.websocket.server.WebSocketUpgradeFilter
to your WEB-INF/web.xml
manually.
This then leaves it up to you to attempt to get your authentication filter to exist before this WebSocketUpgradeFilter
in 100% of use cases.
Caution: filter execution ordering is not part of the servlet spec. Be careful with this, as it might seem to be working on your dev machine and then suddenly not work in QA or production. Simply because the Set of filters in the metadata will have a different order in it.
Notes:
- Path Spec must be
/*
- Async Supported must be
true
- Dispatcher Types must be
REQUEST
only.
- Do not set the
contextAttributeKey
for that filter
- All other WebSocketUpgradeFilter init-params are invalid for JSR-356 use (they are overridden by the various JSR-356 endpoint configurations)