Websockets and cookies

2,886 views
Skip to first unread message

Vincent Le Goff

unread,
Jan 30, 2013, 7:31:48 AM1/30/13
to cherrypy-users
Hi everyone,

I'm using the ws4py (pugin and tool) to use Cherrypy with websockets.
I have some configuration that I would like to store on the
clinet-side. When I have a Websocket objet (handler), can I access
cookies to read and write? I don't think there is an underlying
request, but there may be a way to do it simply.

Thanks,

Vincent

Sylvain Hellegouarch

unread,
Jan 30, 2013, 9:27:20 AM1/30/13
to cherryp...@googlegroups.com
Hi Vincent,

In theory, once you're inside the WebSocket handler, the initiating HTTP request is gone and not usable. WebSocket is a protocol upgrade so when the upgrade has been performed, no more HTTP operations should occur. 

However, ws4py respects CherryPy's dispatching and your CherryPy page handler is called before the upgrade's response is completed. This means that when your CherryPy page handler, you still can act on the HTTP request as per usual, meaning you can set cookies at that stage.

I hope this helps.
--
- Sylvain
http://www.defuze.org
http://twitter.com/lawouach

Vincent Le Goff

unread,
Jan 30, 2013, 12:50:16 PM1/30/13
to cherryp...@googlegroups.com
Hi Sylvain,

Almost what I supposed. Then, it is possible to read the client
cookies before the update is performed, but not write them (or, at
least, not write any cookie after the client is considered connected
to the websocket server).

There are still ways to store client datas. One of them is to store
the data on the server and wait for a new request to arrive from the
same client (how to be sure it's the same one is not much fun, but as
it's not authentication datas it's not such a big deal). That should
work, only if the client sends a new request afterwards.

Do you think of anything I could do otherwise?

Thanks for your quick answer,

Vincent

2013/1/30, Sylvain Hellegouarch <s...@defuze.org>:
> --
> You received this message because you are subscribed to the Google Groups
> "cherrypy-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to cherrypy-user...@googlegroups.com.
> To post to this group, send email to cherryp...@googlegroups.com.
> Visit this group at http://groups.google.com/group/cherrypy-users?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

Sylvain Hellegouarch

unread,
Jan 31, 2013, 3:28:04 AM1/31/13
to cherryp...@googlegroups.com
On Wed, Jan 30, 2013 at 6:50 PM, Vincent Le Goff <vincent.l...@gmail.com> wrote:
Hi Sylvain,

Almost what I supposed.  Then, it is possible to read the client
cookies before the update is performed, but not write them (or, at
least, not write any cookie after the client is considered connected
to the websocket server).


You can write cookies back to the client as long as the request processing is not done. This means that you can definitely write cookies from your page handler. The initial upgrade handshake still requires the HTTP server to properly respond to the HTTP requests. 

It's only that the underlying socket is kept opened afterwards but not usable for HTTP communication anymore.

 

There are still ways to store client datas.  One of them is to store
the data on the server and wait for a new request to arrive from the
same client (how to be sure it's the same one is not much fun, but as
it's not authentication datas it's not such a big deal).  That should
work, only if the client sends a new request afterwards.


Hard to tell without knowing what you want to achieve :) 

Vincent Le Goff

unread,
Jan 31, 2013, 3:56:52 AM1/31/13
to cherryp...@googlegroups.com
Hi,

Thanks for replying :) . Well, I would like to store some
configuration informations on the client's side: if he wants to
change the background image, for instance, he can click on a button
but shouldn't do it everytime he connects to the page.

I did find a way, which is not relying on websockets: write the
cookies as part of the client-side application (in jQuery, for me).
If it's necessary, the server may send the informations that the
client has to store through websockets. As long as the same security
policy applies (the cookies content shouldn't be trusted more than the
user 'sinput), it should work.

Thanks again for your help,

Vincent

2013/1/31, Sylvain Hellegouarch <s...@defuze.org>:

Sylvain Hellegouarch

unread,
Jan 31, 2013, 4:04:47 AM1/31/13
to cherryp...@googlegroups.com
On Thu, Jan 31, 2013 at 9:56 AM, Vincent Le Goff <vincent.l...@gmail.com> wrote:
Hi,

Thanks for replying :) .  Well, I would like to store some
configuration informations on the client's side:  if he wants to
change the background image, for instance, he can click on a button
but shouldn't do it everytime he connects to the page.

I did find a way, which is not relying on websockets:  write the
cookies as part of the client-side application (in jQuery, for me).
If it's necessary, the server may send the informations that the
client has to store through websockets.  As long as the same security
policy applies (the cookies content shouldn't be trusted more than the
user 'sinput), it should work.


I think WebSocket's application patterns are still to be matured and I don't believe there is right or wrong at this stage (aside from the obvious security issues that you seem to be aware anyway). At some point, best practices will emerge to determine whether or not configurations like you do should be done in-band or out of band of the WebSocket's channel.

So if you've found the right way for your use case, go with it :)

pkoelle

unread,
Jan 30, 2013, 6:31:57 PM1/30/13
to cherryp...@googlegroups.com, Vincent Le Goff
Hi Vincent,

I think your problem is not so much tied to cherrypy. Websocket
connections are not like HTTP and you have to "invent" a wire-protocol
or use an existing one like WAMP (wamp.ws). I use WAMP and the first
thing the (javascript) websocket client sends is the cookie. The
connection is then authenticated and I know which user "owns" the
websocket connection.
After that you can easily push data to the client (which would need to
deal with different messages anyway...)

hope that helps
Paul
--
https://ssl.facebook.com/help/contact.php?show_form=delete_account
Reply all
Reply to author
Forward
0 new messages