[undertow-dev] Unified SecurityContext/Exchange/Session for Http and Websockets

Stuart Douglas sdouglas at redhat.com
Sun Nov 22 16:02:11 EST 2015



----- Original Message -----
> From: "Robin Anil" <robin.anil at gmail.com>
> To: undertow-dev at lists.jboss.org
> Sent: Sunday, 15 November, 2015 5:56:28 AM
> Subject: [undertow-dev] Unified SecurityContext/Exchange/Session for Http	and Websockets
> 
> Currently the code path requires separate mechanisms for http and websockets.
> This means the guice scoping logic gets complicated for all business objects
> derived from SecurityContext/Exchange
> 
> For example lets say we are sending a cookie containing a JWT token. For Http
> we have written an Authentication mechanism which creates a security context
> and then a guice injector which gets the authenticated data from the
> security context Principal.
> 
> Now if we need to support websockets, firstly the authentication mechanism is
> non existent.

Websockets is expected to piggy back on HTTP authentication, i.e. you should authenticate the initial request. The websocket protocol itself does not support authentication.

> 
> Another example is the Headers. In HttpServerExchange the headers are in a
> HeaderMap but for websockets it is a Map<String, List<String>>. The
> injection code that worked off HeaderMap now no longer work in Websocket
> context.

This representation was chosen because this is how JSR-356 expects the headers (e.g. javax.websocket.server.HandshakeRequest#getHeaders). 

Stuart

> 
> 
> I feel like this can be improved if there are shared interfaces for these
> core objects across Http and Websockets so that it becomes easy for
> downstream code to re-use business object injection logic across the two
> 
> Thoughts?
> 
> 
> Robin
> 
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev


More information about the undertow-dev mailing list