Ludovic Praud opened SPR-8997 and commented
I was waiting the flash attributes feature in spring 3.1 but I was surprised that the attributes were stored in the HTTP session instead of cookie. My webapp is required to not have session because the infrastructure we use does not handle sticky session. I have done my own flash scope inspired from the one in playframework. It would be cool to be able to choose between http session or cookie.
Affects: 3.1 GA
Issue Links: - #17354 FlashMap's cannot be easily serialized by means other than java serialization
4 votes, 10 watchers
Comment From: spring-projects-issues
Rossen Stoyanchev commented
There is a DefaultFlashMapManager with a method called retrieveFlashMaps that can be overridden. To plug a custom implementation, just register it as as a bean named "flashMapManager" in the DispatcherServlet WebApplicationContext. Feel free to experiment with that. If you get something to work in your environment, consider submitting a patch via github.
Comment From: spring-projects-issues
Ludovic Praud commented
FlashMapManager does not provide access to HttpServletResponse, so cookie cannot be stored to the response request. Moreover FlashMap object does not provide access to its timeToLive, so we cannot set the cookie maxAge.
Comment From: spring-projects-issues
Rossen Stoyanchev commented
Thanks for the feedback. The FlashMapManager now provides access to the HttpServletResponse. The time to live for a FlashMap is controlled by the caller of its startExpirationPeriod(int) method. I've added a getter to DefaultFlashMapManager providing access to its flashMapTimeout field. That should provide what you need but if not let me know.
Comment From: spring-projects-issues
Thomas Recloux commented
Hi, I'm trying to implement a cookie Based FlashMapManager, but the requestCompleted method is called after the view rendering. Then the response is commited and no cookie can be added to the response. I think the requestCompleted could be called in the DispatcherServlet.doDispatch method, before the doRender call. What to you think of it ? Do you want me to submit a patch ? Thanks.
Comment From: spring-projects-issues
Rossen Stoyanchev commented
We have a ticket to address this (see #13699). The timing of your comment couldn't be better!
Keep in mind that RedirectView sets target request information on the output FlashMap and that needs to happen before the FlashMap is saved. We'll probably have to do something in RedirectView. We'll look to address this pretty soon as part of #13699 so please add further comments there or watch it.
Comment From: spring-projects-issues
Rossen Stoyanchev commented
@Thomas, @Ludovic, there is a commit in the 3.1.x branch that should make what you're trying to much easier (commit 3d1fa4). Please, give it a try if you can and thanks for your help!
Comment From: spring-projects-issues
Thomas Recloux commented
Thank you Rossen for this great Work. I created a sample project in order to test the cookie based implementation. Source code is there : https://github.com/trecloux/spring-flash-cookie (See IntegrationTest class)
Storing an attribute and retrieving it after the redirect is OK. My problem is now to cleanup the Cookie in order to remove the attribute. I would need an access to the response in the getFlashMapForRequest method.
Do you want me to submit a pull request ?
Comment From: spring-projects-issues
Rossen Stoyanchev commented
It looks like the change went pretty far but not far enough. I experimented with the example and in the process made the requested change along with a couple of improvements. The change is in the 3.1.x branch now and will be in master (3.2.x) soon but in the mean time, just switch to 3.1.1.BUILD-SNAPSHOT and the sample should work without any further changes. Hopefully this takes care of it but if not feel free to submit a pull request. Thanks!
Comment From: spring-projects-issues
Thomas Recloux commented
Again It is a great Work. And my sample is now fully "Green".
Are you interesseted by the Cookie based implementation ?
Comment From: spring-projects-issues
Rossen Stoyanchev commented
Yes, we will need something like that for this ticket. I wonder if you considered using Java serialization? It would make the implementation more broadly available.
Comment From: spring-projects-issues
Thomas Recloux commented
It was my first idea, but I realized that the serialized data was really huge in regard of the small amout of data saved in the Map. I'm not fixed on the JSON and/or Jackson solution, the main goal was to test the API and to, prototype a quick solution.
I will browse all solutions and come back to you.
Comment From: spring-projects-issues
Ludovic Praud commented
@Thomas, @Rossen : about the serialization, I think Thomas is near something simple and portable with JSON. I don't feel comfortable with Java serialization as it is complicated, obfuscated... The serialization of data to cookie should be small (less than 4kB), text based (may be base64 but not much) and portable enough to be used by JavaScript browser application because even if the first use of flash map is about redirection, future use will be as application user session. What do you think ?
Comment From: spring-projects-issues
Benedek Fazekas commented
hi Guys,
really nice feature! agree with Ludovic preferring json over java serialization, however don't agree with him on ruling out the encoding of the cookie. I do think that only using base64 raises some security issues namely using this feature the developer would definitely disclose the innards of the server side for the client even if it is for only a short time. so at least the option to strongly encode (before base64) the cookie should be added i think.
Comment From: spring-projects-issues
Thomas Recloux commented
I also agree on the strong encoding It is in my TODO list.
Comment From: spring-projects-issues
Thomas Recloux commented
Hi Guys, One year later, I published a first version on the cookie based flash map manager. Encryption is now mandatory.
To enable this component : - add dependency : (available in maven central)
\
Please give a try and send me your feedback :)
Comment From: spring-projects-issues
Rossen Stoyanchev commented
Thanks Thomas, I'll have a look! Just wondering if your intent is to submit a pull request or keep it as a separate project?
Comment From: spring-projects-issues
Thomas Recloux commented
Hi Rossen, I'll be happy to submit a pull request if it can be integrated.
Comment From: spring-projects-issues
Rossen Stoyanchev commented
Thomas Recloux, I've had an initial look. Thanks for making that available!
It's reasonably straight forward. A couple of things. Did you try serializing List<FlashMap> as-is rather than converting to a List<Map<String,Object>>?
Also I see serialization and encryption as good targets points of variation -- e.g. to use different libraries . One option is to introduce a base class with abstract methods for encoding/decoding. However since serialization and encryption may need to vary independently, perhaps a delegate strategy is better. For example FlashMapCodec with methods to go both ways List\
What do you think?
Comment From: spring-projects-issues
Thomas Recloux commented
Thanks for your feedback.
When serializing List<FlashMap>, the specific attributes are not serialized, I think that jackson has special handling for Maps. I will have a deeper look.
I agree with the delegate strategy for serialization / encryption.
I started to move the code to a spring-framework fork.
Comment From: samuelstein
What is the actual status of the ticket?
I recently also experienced problems when using flash attributes in a replicated service.
For me it was not clear enough from the documentation that flash attributes don't use a cookie like play framework but instead a session. Especially when the session creation policy of the app is set to stateless.
I wish at least a warning log entry in this case.
Comment From: bclozel
I'm declining this issue as we haven't made progress on this for a very long time and there is a significant amount of work to be done still, for very little demand. There are still a few key issues to be worked out in the implementation: as mentioned earlier in this thread, the cookie size, encryption and integrity are important security problems.
In the meantime, Spring Session provides secure session replication that's independent of the Servlet container and supports several data stores.