Arthur Koziel

Ever since Ruby on Rails introduced flash messages, it has become a widely popular feature which got ported to various other frameworks such as Symfony and is also available as a custom middleware for Django.

The RoR API documentation describes a flash as a:

“… way to pass temporary objects between actions. Anything you place in the flash will be exposed to the very next action and then cleared out. This is a great way of doing notices and alerts …”

However, many developers tend to use it for more than just “doing notices and alerts”, like passing  critical variables. This might not be a functional idea in the day and age of Tabbed Browsing since request variables like flash attributes are set browser-wide, each new tab on the same controller causes the flash value to be overwritten.

Meaning that if you have 5 tabs opened and each tab points to the same page (but has different request variables) the same flash attribute gets overwritten multiple times. The flash value from the most recent opened tab is used for all 5 tabs. If the next action of your application relies on that specific flash attribute, it might produce some unexpected results.

Example: A Blog

Think of a simple blog which shows a listing of various entries on the frontpage. With a click on an entry, it simply gets shown with a comment form. The entry id for the comment form is passed via a flash rather than a hidden field.

If the user opens up multiple blog entries from the frontpage in new tabs, each tab sets the entry id flash again. When the first tab gets opened, the flash attribute has the value of the last opened entry - a written comment would be associated with the last opened entry rather than the first opened entry.

Conclusion: Sticking to hidden fields and validating it’s value properly might (still) be the best idea.

Published: April 9, 2008 — Tagged: application design, flash, session