Skip to main content

[jsr356-experts] Re: [jsr356-users] Re: WebSocket Session/HttpSession

  • From: Danny Coward < >
  • To:
  • Cc: Mark Thomas < >
  • Subject: [jsr356-experts] Re: [jsr356-users] Re: WebSocket Session/HttpSession
  • Date: Tue, 13 Nov 2012 14:56:45 -0800

Hi Mark,

<snipping earlier conversation in the interests of bevity>
" type="cite">
There are multiple factors here:
- is an HttpSession present (Yes/No)
- is the WebSocket endpoint protected by a security constraint (Yes/No)
- what authentication mechanism is in use (BASIC/DIGEST/FORM/
  CLIENT-CERT/CONTAINER-SPECIFIC)
- logout / session expiration

That gives us at least 32 (actually a few won't work but ignoring that
for now) combinations plus an additional 8 for each container specific
authentication mechanism.

We either need to be clear about what happens in each of the above cases
or provide the hooks to enable the developer to make the choice (with
some sensible defaults). I prefer the latter option.
OK so I think having the developer make that association is reasonable. (see below)

I am still concerned about containers that use the HttpSession for authenticated state running web sockets after the authenticated state has been reset. As you say, this may only be in the FORM login case, but I'm not sure that there aren't other containers and other schemes where the HttpSession is used for more than that one case.

It feels like we need to require containers to close web sockets opened on the understanding of a particular authenticated state in those cases where the authenticated state has changed for whatever reason.

If this makes sense, can you think of a requirement we can put in the spec to capture this succinctly ?

In terms of supporting developers making their own association between httpsessions and web sockets, currently we have

Object HandshakeRequest.getSession()

and we can recommend developers use an HttpSessionListener to track the session to establish whatever relationship they want with it over its lifetime.

We didn't want an explicit dependency on the Servlet API which explains (perhaps not excuses) the typeless API. This seems a step better that asking developers to pull the SessionID out of the Cookie or JSession ID parameter on the request URI, but perhaps a step worse than allowing the HttpSession to be injected explicitly ?

What do others think ?

- Danny


" type="cite">
Mark



--
Danny Coward
Java EE
Oracle Corporation


[jsr356-experts] Re: WebSocket Session/HttpSession

Greg Wilkins 11/01/2012

[jsr356-experts] Re: WebSocket Session/HttpSession

Danny Coward 11/02/2012

[jsr356-experts] Re: WebSocket Session/HttpSession

Mark Thomas 11/03/2012

[jsr356-experts] Re: [jsr356-users] Re: WebSocket Session/HttpSession

Danny Coward 11/08/2012

[jsr356-experts] Re: [jsr356-users] Re: WebSocket Session/HttpSession

Mark Thomas 11/09/2012

[jsr356-experts] Re: [jsr356-users] Re: WebSocket Session/HttpSession

Danny Coward 11/13/2012

[jsr356-experts] Re: [jsr356-users] Re: WebSocket Session/HttpSession

Mark Thomas 11/14/2012

[jsr356-experts] Re: [jsr356-users] Re: Re: WebSocket Session/HttpSession

Danny Coward 11/15/2012

[jsr356-experts] Re: [jsr356-users] Re: Re: WebSocket Session/HttpSession

Mark Thomas 11/24/2012

[jsr356-experts] Re: [jsr356-users] Re: Re: WebSocket Session/HttpSession

Greg Wilkins 11/29/2012
 
 
Close
loading
Please Confirm
Close