Indeed, this effect has existed since the early days of Rails. It is so much a part of Rails' legacy that most of the non-technical people I work with are aware of it as an artifact of Rails specifically.
-Jason > On May 26, 2015, at 7:27 PM, Will Bryant <will.bry...@gmail.com> wrote: > > It’s deliberate - if you don’t access the flash, then you clearly haven’t > rendered the message, so it should stay until a request that does. > > Otherwise any random request (say an AJAX autocompleter) that happens to come > in before the next page request (which is the one we intend to show the flash > message) will steal the flash value and throw it away. > > There was another problem with clearing the flash hash on every request. > There was a period when rails did do this, and it caused a massive security > problem for one of my projects: hitting the flash meant accessing the session > variable, and since the ability to explicitly turn off the session in certain > controllers was removed a long time ago, this meant that all requests > accessed the session variable. Which meant they all wrote the session > variable, because Rails writes the session cookie back out if the session was > loaded. Which meant if you had a request that said the response was > cacheable, all the users hitting that action got the cached session cookie of > some other user… > > More generally, it’s not intended that all controller actions will load and > set the session, even if they don’t use it. It’s supposed to be lazy-loaded > as you say, and that means the flash is too. > > I don’t understand why you are putting stuff into the flash hash if you don’t > actually want to render it again though? It’s specifically there to put > stuff into the session to be renderd by the next layout request. > > Just use an ordinary ivar if you don’t want that. > > >> On 27/05/2015, at 03:10 , Garry Shutler <ga...@robustsoftware.co.uk >> <mailto:ga...@robustsoftware.co.uk>> wrote: >> >> I posted this to the talk mailing list >> <https://groups.google.com/forum/#!topic/rubyonrails-talk/ulfHtDvtNM4> but >> got no response, not sure if this list is more suitable. >> >> As the subject suggests, I'm not sure if this is a bug or a feature. >> >> If I have an action that sets something in the flash and redirects to an >> action (to pre-empt the "flash.now" responses) that renders something but >> does not touch the flash at all then the values will remain in the flash for >> following requests to pick up. This could potentially be an infinite number >> of requests later if none of the requests in between touch the flash. >> >> I believe this is because Request.flash is lazily loaded >> <https://github.com/rails/rails/blob/e6d8f435a921dce360bce9faae7dabaf753d4d23/actionpack/lib/action_dispatch/middleware/flash.rb#L9> >> but only swept (as a side effect of to_session_value >> <https://github.com/rails/rails/blob/e6d8f435a921dce360bce9faae7dabaf753d4d23/actionpack/lib/action_dispatch/middleware/flash.rb#L103>) >> if it has been lazy loaded >> <https://github.com/rails/rails/blob/e6d8f435a921dce360bce9faae7dabaf753d4d23/actionpack/lib/action_dispatch/middleware/flash.rb#L269>. >> >> Touching the flash in anyway (even without using it) will produce the >> behaviour I expect of the flash being cleared in the request following the >> redirect and so no further requests being able to access it. This means I >> can use an after_action or similar to ensure it is always loaded and get the >> behaviour I expect. >> >> Is the current behaviour expected? >> >> If it is, I have a work around and hopefully this will exist on Google for >> other people who expect it to work as I do. If it isn't, I'm happy to look >> into it and create a pull request. >> >> Cheers, >> Garry >> >> Garry Shutler >> @gshutler <http://twitter.com/gshutler>gshutler.com <http://gshutler.com/> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Ruby on Rails: Core" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to rubyonrails-core+unsubscr...@googlegroups.com >> <mailto:rubyonrails-core+unsubscr...@googlegroups.com>. >> To post to this group, send email to rubyonrails-core@googlegroups.com >> <mailto:rubyonrails-core@googlegroups.com>. >> Visit this group at http://groups.google.com/group/rubyonrails-core >> <http://groups.google.com/group/rubyonrails-core>. >> For more options, visit https://groups.google.com/d/optout >> <https://groups.google.com/d/optout>. > > > -- > You received this message because you are subscribed to the Google Groups > "Ruby on Rails: Core" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to rubyonrails-core+unsubscr...@googlegroups.com > <mailto:rubyonrails-core+unsubscr...@googlegroups.com>. > To post to this group, send email to rubyonrails-core@googlegroups.com > <mailto:rubyonrails-core@googlegroups.com>. > Visit this group at http://groups.google.com/group/rubyonrails-core > <http://groups.google.com/group/rubyonrails-core>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. ---- Jason Fleetwood-Boldt t...@datatravels.com http://www.jasonfleetwoodboldt.com/writing -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/d/optout.
