I’m trying to save and later retrieve a user’s login name. For that I need a cookie. To write a cookie, I need the current VaadinResponse so I can call addCookie. But when I call VaadinService.getCurrentResponse I get a null.
When I dribble lines like the following throughout my Vaadin app’s code:
logger.trace( "ResponseStatus in xyz-method: " + VaadinService.getCurrentResponse() );
…I seem to always get a VaadinResponse object except where I need it most, in my login dialog’s login button’s listener.
What makes a VaadinResponse come and go? At what point in a Vaadin app can I write a cookie?
Writing the cookie from a click event sounds like a good place to do it. How did you create your dialog?
Remember VaadinService.getCurrentResponse() cannot be accessed from background threads.
Turns out that enabling Push and using the WebSocket mechanism breaks Cookie writing. The VaadinResponse object goes away because after engaging WebSocket you have an open communications channel between browser and server, so no more request-response cycles.
Actually, you may be able
read cookies but not
write them, under Push + WebSocket, at least early in your session before the connection has been upgraded to engage WebSocket. This results in an unfortunate predicament of one-way cookies. Imagine the user of a Push-enabled Vaadin app is on a network where WebSocket is blocked (proxy server, firewall, and such). With no WebSocket, some cookies were written to remember the user’s input such as “user name”. Good. Later that user moves that computer/device to a network where WebSocket does work, so writing cookies fail. From now on the user sees the old loaded value (user name), but any changes are never saved. The cookie will never be updated.
Some folks claim that Cookies could be supported under WebSocket. But the secure form of Cookies (HTTP-only) by definition should not be manipulated via JavaScript (according to my limited understanding). And anyways, the Atmosphere library used by Vaadin for Push does not support Cookies over WebSocket. So for now, no go.