This patch hardens scaffold-generated code against client-side caching issues introduced by Google Web Accelerator and the like. Although Rails scaffolding is not intended to be used in production, there is little doubt that a substantial number of Rails developers use scaffolding as production code, either wholesale or with stylesheet changes only. Even if we assume that scaffolding never ends up in production, it does have great value as a design guide for authors of Rails controllers and views. Wherever possible, Rails examples--including scaffolds--should encourage defensive coding against threats such as GWA.
Hardened scaffolding performs state-changing create, update and destroy logic only when those actions are invoked by HTTP POST requests. When HTTP methods other than POST are used, the results are as follows:
* The create action redirects to new with the notice "<%= model_name %> must be created using HTTP POST"
* The update action redirects to edit with the notice "<%= model_name %> must be updated using HTTP POST"
* The destroy action redirects to edit with the notice "Click Destroy to destroy <%= model_name %>"
In addition to controller code changes, there are associated view code changes:
* The link for destroying an item in the list view now sets to true the link_to() :post option
* A button for destroying the item has been added to the edit view
The upshot of this is that no state changes occur when GWA follows the links to destroy items. If scripting is disabled in the client, the user's click on the Destroy link of a list will take him to the edit page, and a notice will inform him to click the Destroy button.
The test code generator functional_test.rb has been updated to reflect the hardened behavior of generated controllers.
There is one little cosmetic change to the list action of generated controllers. I inserted parentheses into the call to paginate() because it appears on the right side of an assignment statement.
