+1
Carrying the Session along would jsut complicate the API. Handing it off
at handshake time would let the devs grab it they want or not.
On Fri, Aug 10, 2012 at 10:12 PM, Greg Wilkins <gregw_at_intalio.com> wrote:
> Danny,
>
> Good analysis.
>
> But just to clarify my position....
>
> I think that when a handhake is accepted, that is when the both a HTTP
> request and a Websocket endpoint exist at the same time. I think at that
> point the developer should copy any state that they want (eg UserPrincipal)
> from the request/session to the POJO that is the websocket endpoint.
> The state injected into the endpoint might just be a reference to the
> HttpSession (which is probably safe) or a reference to the ServletRequest
> (which is unsafe and will break). Of the point has the session, then it
> should be able to touch it to keep it alive and access attributes so as to
> be able to communicate with HTTP requests accessing the same session. But
> the key thing is that I don't think the EndPoint API should make the
> HttpSession explicitly available, as that introduces a portability issue
> and because it is easy to inject the session as the endpoint is created
> during the handshake.
>
> cheers
>
>
>
>
>
>
>
>
>
> On 10 August 2012 09:58, Danny Coward <danny.coward_at_oracle.com> wrote:
>
>> Here's a few thoughts since this thread has sort of ended up talking
>> about web socket connections and Http Sessions.
>>
>> HttpSession is only an embodiment of the sequence Http calls from the
>> same web client into the web server where the web sockets are, and from our
>> perspective, the opening handshakes from one web client to one or more of
>> the web sockets are some those calls. There might have been several calls
>> (including an authentication interaction) before the web client sent each
>> opening handshake. The same web client may have sent several different
>> opening handshakes, each for a different web socket. There might be lots
>> more plain http requests and/or opening handshakes coming from the same web
>> client before the day is done.
>>
>> So we have one HttpSession per web client. Embodies all the http requests
>> it made. (some of them handshakes, some of them not).
>>
>> Then, per web-socket-client-server pair, we have (logically) one
>> connection. We're modeling this in the API as a Session. The Session
>> appears with the Open frame, and dies when the connection ends.
>>
>> So we have one Session per connection. Since each web client can create
>> multiple web-socket-clients, there are multiple Sessions for each
>> HttpSession. Since web developers often put all sorts of useful information
>> in the HttpSession, I think it'd be useful to expose this into web socket
>> sessions (as v003 of the API does).
>>
>> How we relate the lifetimes of Sessions and HttpSessions is going to
>> depend in part how we want to do the security model for web sockets.
>>
>> I'll throw out a few scenarios that perhaps we should make easy for
>> developers to create:-
>>
>> 1. if a web client has already authenticated with the server (using one
>> of the standard EE methods for example: HttpBasic, form or client cert)
>> then an opening handshake from the same client should be treated as already
>> authenticated.
>>
>> 2. it should be easy for a web socket developer to declare whether
>> access to a web socket server endpoint needs to be authenticated, and who
>> can access it, and if it needs an encrypted connection or not. Maybe this
>> is as simple as treating the ws:// URLs as falling under the same
>> security model as the web container uses for its web resources?
>>
>> 3. in a web application, if the client doesn't make any interactions for
>> a long time, but the web socket connections that the client opened up are
>> in use (or have not expired), then for many developers, this will mean they
>> think of the client as being still active, and it should be easy configure
>> things so that HttpSession does not expire on the web sockets (maybe by
>> 'touching it' as I think Greg suggested.
>>
>> 4. in a web application where all the resources require authentication
>> and an access check to access (web content and web socket content alike),
>> if the client 'logs out' then the client should not be able to access any
>> of the content any more (including the web sockets).
>>
>> Do you agree ? Are there others ?
>>
>> - Danny
>>
>>
>>
>>
>> On 8/9/12 8:43 AM, Joe Walnes wrote:
>>
>> I agree that sharing a full blown HttpSession introduces a lot of
>> complexity, and if we can avoid it, we should.
>>
>> Authentication is really the only case I can think of where state needs
>> to be shared, so maybe we can specifically handle this, rather than coming
>> up with a general catch-all solution.
>>
>> If the EndPoint instance had access to the user principal (and maybe
>> the URI and headers from the original request, to allow other pieces of
>> information to be passed from a web-page to a WebSocket), that should me
>> enough, right?
>>
>> On Thu, Aug 9, 2012 at 9:03 AM, Justin Lee <jlee_at_antwerkz.com> wrote:
>>
>>> i'm with greg on this one. In grizzly, we'd create a new WebSocket per
>>> connection and save state there. In the WebSocketApplication class, there
>>> was an overridable factory method that allowed for specialization at the
>>> application layer that let the app author do whatever was needed. With
>>> access into the Application from a WebSocket, state could be shared exposed
>>> as needed. I'm not entirely sure we need to work too hard to deal with
>>> things like shared credentials on multiple connections from a client since
>>> muxing alleviate that multiple connection problem when it lands. That
>>> said, it's up for debate how much we want to plan around impending features
>>> (that might be impending for a year+) or just design to what we have *now*
>>> that we know browsers and clients support.
>>>
>>>
>>> On Wed, Aug 8, 2012 at 7:56 PM, Joe Walnes <joe_at_walnes.com> wrote:
>>>
>>>>
>>>>
>>>> On Wed, Aug 8, 2012 at 6:47 PM, Greg Wilkins <gregw_at_intalio.com>wrote:
>>>>
>>>>> On 5 August 2012 19:05, Mark Thomas <mark_at_homeinbox.net> wrote:
>>>>> > The question this raises for me is what is the mechanism going to be
>>>>> for
>>>>> > retaining state? i.e. what is the WebSocket equivalent of HttpSession
>>>>> > going to be? The follow-on question is how is state information
>>>>> > transferred between the WebSocketSession (for want of a better name
>>>>> > right now) and the HttpSession.
>>>>>
>>>>> In my websocket work to date, having websocket session has not been an
>>>>> issue as we create an EndPoint per connection as a new object that can
>>>>> hold state.
>>>>>
>>>>
>>>> That's true, but there's also some state that needs to be shared
>>>> between connections such as authentication credentials.
>>>>
>>>>
>>>
>>>
>>> --
>>> You can find me on the net at:
>>> http://antwerkz.com http://antwerkz.com/+
>>> http://antwerkz.com/twitter http://antwerkz.com/github
>>>
>>>
>>
>>
>> --
>> <http://www.oracle.com> * Danny Coward *
>> Java EE
>> Oracle Corporation
>>
>
>
>
> --
> Greg Wilkins <gregw_at_intalio.com>
> http://www.webtide.com
> Developer advice and support from the Jetty & CometD experts.
>
--
You can find me on the net at:
http://antwerkz.com http://antwerkz.com/+
http://antwerkz.com/twitter http://antwerkz.com/github