On Oct 13, 2007, at 9:03 PM, Luzzy wrote:
Instead, passwords should only be changed after they submit a very
paticular form, and after they confirm the change through email.
Are there any ideas on how to lock down certain values in a model
after its initial creation?
This sounds to me like you’re expecting that an update via
ActiveRecord will automatically write any data it recieves from a
form. So, if you have a form that is intended to update a user’s
name, and they copy the HTML, then add a password field that they
collected from the original account create form, then submit that
version, you’re suspicious that the password data actually makes it
all the way through to the database. Is that what you’re worried about?
Me too. I’m new to Rails, and haven’t yet figured out what it has
to protect against this situation, but in my own framework, my form
processing had a required attribute which is an explicit list of
allowed inputs by name. SQL was generated based on which inputs were
submitted, but no matter what gets sent by POST or GET, and no matter
even if you handed over the entire params array, the SQL generator
would only allow those explicitly named inputs to become part of the
IMO, it’s an essential part of input validation. Accept only what you
want to accept applies to the actual field count in addition to date/
format per field. To me the protection you’re looking for doesn’t
belong as a state of attribute in the model, it belongs at the poing
of filtering the form to start with. That’s how you achieve fields
being changed by “a very particular form.”
I would suspect Rails has some mechanism for this input filtering,
but I haven’t gotten that far yet.