[WEBSOCKET_SPEC-5] Define relationship between HttpSession and Web Socket Sessions. Created: 21/Sep/12  Updated: 13/Dec/12  Due: 09/Nov/12  Resolved: 13/Dec/12

Status: Resolved
Project: websocket-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: dannycoward Assignee: dannycoward
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: v010


We want these two things to be true:

1)if the web socket is a protected resource in the web application, that is to say, required an authorized user to access it, and the user explicitly invalidates the HttpSession, the websocket implementation must close the web socket connection immediately

2) if the user of the web application is actively using the web sockets within the web application, but does not access any of the web resources, the web socket implementation must keep the HttpSession from timing out (TBD This a request to the servlet specification).

This is because authentication state is carried in the Http Session.

But what about the unauthenticated case ? Does an explicit invalidate need to close the web sockets ? Does a timeout matter ?

Comment by dannycoward [ 07/Dec/12 ]

1) The only association between websocket session and HttpSession is at opening handshake time. The API gives developers a convenient access to the HttpSession object at that point in time.
2) The user identity associated with the websocket Session is the user identity that was established at the opening handshake.
2) If the server decides that authorization for this websocket resource by this user identity has ended (it expired, or some logout mechanism was invoked) then the websocket implementation must immediately close the connection.

(from my read of the websocket spec, the most suitable close code for the latter is 1008).

Comment by dannycoward [ 13/Dec/12 ]

This has been updated in v010 of the spec, per my comment.

Generated at Thu Dec 08 12:24:30 UTC 2016 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.