Re: [undertow-dev] Unified SecurityContext/Exchange/Session for Http and Websockets
----- Original Message -----
From: "Robin Anil" <robin.anil(a)gmail.com>
To: undertow-dev(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/undertow-dev