Re: [hybi] [whatwg] HttpOnly cookie for WebSocket?

[Salvatore Loreto <[e-mail]>]

Hi,

thanks to have moved back to the original question.
My original mail my was a call to discuss the technical aspects openly 
in the mailing list, so to let the spec move forward.


I agree that it would be useful to use cookie on WebSocket,
however I have some perhaps stupid doubts and questions on its usage 
that I'd like to be clarified

1) Is the usage of cookies optional or it is mandatory?
what will happen in the few cases where the WebSocket will be 
established without the user has already logged into a page?

2) another aspect that leaves me doubtful is leverage HTTP aspect for 
WebSocket.
     If I remember correctly (please correct me if I am wrong), Ian 
Hickson has several time underlined the fact that WebSocket
     is an independent protocol from HTTP, it just and only reuses in 
the handshake the HTTP syntax for opportunistic reasons;
     however  starting to leverage on more and more HTTP features let me 
think that WebSocket is not or can not be considered independent
     anymore.

3) Ian Fette, when you say "...the server logic to check whether a user 
is already logged in..." it appears to me that you are relaying on the
     assumption that a specific technology/language is used to implement 
this usage.
     A protocol should be neutral from the languages and technologies, 
and just describe the steps that need to be followed.


thanks in advance for all the clarifications
/Sal
www.sloreto.com



On 01/29/2010 12:49 AM, Ian Fette (????????) wrote:
> So, moving back to the original question... I am very concerned here. 
> A relatively straightforward question was asked, with rationale for 
> the question. "May/Should WebSocket use HttpOnly cookie while 
> Handshaking?
> I think it would be useful to use HttpOnly cookie on WebSocket so that 
> we could authenticate the WebSocket connection by the auth token 
> cookie which might be HttpOnly for security reason."
>
> It seems reasonable to assume that Web Sockets will be used in an 
> environment where users are authenticated, and that in many cases the 
> Web Socket will be established once the user has logged into a page 
> via HTTP/HTTPS. It seems furthermore reasonable to assume that a 
> server may track the logged-in-ness of the client using a HttpOnly 
> cookie, and that the server-side logic to check whether a user is 
> already logged in could easily be leveraged for Web Sockets, since it 
> starts as an HTTP connection that includes cookies and is then 
> upgraded. It seems like a very straightforward thing to say "Yes, it 
> makes sense to send the HttpOnly cookie for Web Socket connections".
>
> Instead, we are bogged down in politics.
>
> How are we to move forward on this spec? We have multiple server 
> implementations, there are multiple client implementations, if a 
> simple question like this gets bogged down in discussions of WHATWG vs 
> IETF we are never going to get anywhere. Clearly there are people on 
> both groups who have experience in the area and valuable contributions 
> to add, so how do we move forward? Simply telling the folks on WHATWG 
> that they've handed the spec off to IETF is **NOT** in line with what 
> I recall at the IETF, where I recall agreeing to the two WGs working 
> in concert with each other. What we have before us is a very trivial 
> question (IMO) that should receive a quick response. Can we use this 
> as a proof of concept that the two groups can work together? If so, 
> what are the concrete steps?
>
> If we can't figure out how to move forward on such a simple issue, it 
> seems to me that we are in an unworkable situation, and should 
> probably just continue the work in WHATWG through to a final spec, let 
> implementations settle for a while, and then hand it off to IETF for 
> refinement and finalization in a v2 spec... (my $0.02)
>
> -Ian
>
> 2010/1/28 Ian Hickson <[e-mail] <mailto:[e-mail]>>
>
>     On Thu, 28 Jan 2010, Julian Reschke wrote:
>     > Ian Hickson wrote:
>     > > ...
>     > > > The WHATWG submitted the document to the IETF
>     > >
>     > > I don't think that's an accurate portrayal of anything that
>     has occurred,
>     > > unless you mean the way my commit script uploads any changes
>     to the draft to
>     > > the tools.ietf.org <http://tools.ietf.org> scripts. That same
>     script also submits the varous
>     > > documents generated from that same source document to the W3C
>     and WHATWG
>     > > source version control repositories.
>     > > ...
>     >
>     > By submitting an Internet Draft according to BCP 78 you grant
>     the IETF certain
>     > rights; it's not relevant whether it was a script or yourself
>     using a browser
>     > or a MUA who posted it.
>     >
>     > You may want to check
>     <http://tools.ietf.org/html/bcp78#section-5.3>.
>
>     With the exception of the trademark rights, which I don't have and
>     therefore cannot grant, the rights listed there are a subset of
>     the rights
>     the IETF was already granted by virtue of the WHATWG publishing
>     the spec
>     under a very liberal license. So that doesn't appear to be relevant.
>
>     --
>     Ian Hickson               U+1047E                )\._.,--....,'``.
>        fL
>     http://ln.hixie.ch/       U+263A                /,   _.. \   _\
>      ;`._ ,.
>     Things that are impossible just take longer.  
>     `._.-(,_..'--(,_..'`-.;.'
>     _______________________________________________
>     hybi mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/hybi
>
>