-
Notifications
You must be signed in to change notification settings - Fork 729
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support cookies when using websockets for push #3911
Comments
Originally by @jdahlstrom This is, unfortunately, by design. The Websocket protocol is completely separate from HTTP and does not have anything resembling HTTP requests and responses (excepting the initial handshake which looks like HTTP for compatibility reasons.) So, for example, setting response headers would make little sense. With the various AJAX-based push fallbacks such as streaming and long-polling the request and response are there and could be exposed via Is this simply a documentation issue or do you have a use case in mind that could somehow be implemented even given the above limitations? |
Originally by tleveque My problem is that I need to create and read cookies. |
Originally by @jdahlstrom We could expose a cookie API in |
Originally by tleveque Not sure what you mean by httpOnly cookies (versus what?), but you really need to implement that before the final version of version 7.1 otherwise it will break a lot of application without real workaround. |
Originally by @jdahlstrom https://www.owasp.org/index.php/HttpOnly Basically, if the A workaround is, of course, not using push. Seriously, depending on when you need to set/read cookies, you might be able to set One way to implement this that works with Anyway, this is an unfortunate limitation in the current implementation, but breaks no legacy code, so I'm changing this ticket into an enhancement request. We'll need to think about this a bit. |
Originally by @wolfie There is no reliable way to fix this directly. There were a few options we considered:
We deemed that these solutions would be too hazardous to implement, since the long-term side-effects in all corner cases are unknown. Some quick prototypes seemed to work, but we had no chance of verifying those. Also, we would've needed to diverge our fork of Atmosphere even further, which we are very reluctant to do, considering we still need to keep up to date with the upstream in the future. This ticket and a related #11721 (both which stem from very related issues - not being able to access the original http session/http request objects) will be closed with the resolution "wontfix". Instead, this issue was decided to be fixed with the help of #12518 (so you should follow and vote on that ticket instead). We don't want to fix the individual symptoms, but we'd rather work around the issue by providing a more rigorous solution to this, and any related problems. |
Originally by @Artur- Updated summary to reduce confusion. This issue is only related to websockets, not long-polling or streaming (or any HTTP request based push mechanism) |
Originally by sv Is it bad to do it like that ?
for non HttpOnly cookies |
Originally by @Legioth Using Vaadin's For reading cookie values, you'd need to use |
Originally by @Artur- In Vaadin 7.6 you can use WEBSOCKET_XHR to get around this limitation. In that case, only explicitly pushed messages will go through the websockets connection and user interactions as XHR |
I just beat my head against this for a half hour. How about at least updating the Javadoc for |
Hey @archiecobbs, what did you eventually end up doing? I agree with updating the Javadoc. |
@afspear it's not addressed yet. For now, users in my application have to login again after the session times out. |
Originally by tleveque
As soon as I enable the Push (adding the @Push annotation), the VaadinService.getCurrentResponse() method start to return null. Same thing if I put PushMode.MANUAL as the attribute.
Imported from https://dev.vaadin.com/ issue #11808
The text was updated successfully, but these errors were encountered: