My Rails Learning Path: Flash Pitfalls
By divas on Jun 10, 2008
For the past few weeks, I have been working on writing the NetBeans IDE 6.1/Rails 2.0 version of the Building Relationships Between Models tutorial. The NetBeans Ruby community provided helpful guidance, especially Florian Gilcher, who spent a lot of time shaping up the code and teaching me about best practices. Florian moderates the Rails part of Rubyforen.
The first input I got from Florian was actually about the Rails 1.2 version of the tutorial. In this tutorial, they used the flash to pass the post's id from the show action to the show template and from the show template to post_comment action.
Florian pointed out that using the flash to store state information can cause two severe bugs:
Session Time Out Bug. A session is volatile and thus gets erased after a certain amount of time, typically 15 minutes after the last client request. Should a user get a phone call in the middle of writing a comment, the session could be invalidated, creating a new one. When the user submits the comment, the flash is empty and he gets a 500 status. Not good!.
Multiple Request Bug. The flash holds for one unspecified request. If the browser fires off another request, the flash is emptied. Thus a user switching between writing a comment and reading posts on other message boards runs into the same problem as above.
I have the feeling that several of the lab participants at our JavaOne hands-on-lab ran into these exact problems, as they were using the same browser to read the lab steps and run the application. I had not run into these problems when testing the lab or the original tutorial. As Florian pointed out, "The bad thing about both bugs is that they almost never appear in testing environments. I would never sit before my PC writing plain text for 15 minutes, and explain my boss that I was testing ;)."
Instead of using the flash, you can simply add the the id in the call to form_tag (form_tag :action => 'post_comment', :id => @post). This maps to /blog/post_comment/id, which matches the pattern declared by the map.connect ':controller/:action/:id' mapping in routes.rb. An alternative is to pass it in a hidden field. One problem with these solutions is that the data can be tampered with, so you need to make your application able to cope with that. As Florian said, "If the user wants to play madman, he should only be able do this with data he actually is allowed to edit."
So, lesson learned! Fortunately, the NetBeans Ruby 6.1 tutorials use RESTful resources, and thus eliminate this bad practice altogether.