I followed with some interest the debate around the “mass assignment vulnerability” recently reported in Rails. I dislike the way the whole debate is couched assuming access control at the model level. When you are stating that an attribute cannot be assigned, you are stating that to assign this attribute from the controller, you can’t use the normal update_attributes method, and must update it explicitly.
I don’t like the laziness this implies. I believe we should embrace practices that encourage explicit thought about the attributes a controller method can update – encouraging developers to build in an intentional fashion, and consider exactly how each method they build behaves. The role based security in Rails 3.1 is alright. But I still think the definition of which attributes a controller method updates should be made explicit. It isn’t just a security concern. The attributes a controller method can take as input to update a model should be part of the contract of that method, in my opinion. It aids understanding.
I far prefer the ideas of the View Model and Model In Model Out. The input a controller can receive, and the output that is rendered to the view is both explicitly modeled (and therefore documented), and independent of the underlying model. Using a tool such as Automapper can prevent the noise mapping View Model to Model can introduce.
I don’t know the Rails community well enough to know what people are doing in this space. I saw a stackoverflow post that refers to a Presenter patter, but can’t say I’ve looked too closely yet.