Consider re-implementing ProtectedAttributeAssignmentError

A gotcha that has bitten me quite a few times - when you try to mass-
assign a protected attribute, it fails "silently" (but appears in the
debug log). There is some useful discussion about this subject here:

http://dev.rubyonrails.org/ticket/9966

But I thought this worth bringing up after seeing this commit:

http://github.com/rails/rails/commit/108db00aa90fe266564483ab301cf0669cae600f

Perhaps this protected attribute assignment error is worth revisiting
with the addition of the extremely handy rescue_from additions that
have made their way into core?

http://github.com/rails/rails/commit/90c930f45c5c6766306929241462ffff8f67b86e

Of course, I'm getting better about remembering to add attributes via
attr_accessible after being bitten by this one a few times, but
perhaps others have been confounded by this gotcha as well?

Thanks,
- Trevor

I like the idea of assignment to a protected attribute being an
exception. I kinda grok the link to ARes, but it seems that the
change in AR is overly "practical" and doesn't pass the sniff test:
assigning to a protected attribute looks like an exception, it can be
severe (security-wise) and it used to be an exception.

The silent dropping of values bugs me, but in this case I think the
cure is worse than the disease. When we had it enabled previously all
of my exception trackers were spammed with dozens of random junk
coming from adventurous users or broken spam bots.

The current behaviour doesn't have any security related downsides, and
it's just being slightly postel-friendly in the way it behaves.

We could add a hook to make it easier for plugins to handle this
situation, but at present I think it's just a little too annoying for
enabling it by default.

The silent dropping of values bugs me, but in this case I think the
cure is worse than the disease. When we had it enabled previously all
of my exception trackers were spammed with dozens of random junk
coming from adventurous users or broken spam bots.

I would love it if this would only raise an exception in
non-production environments.

steven bristol

Yeah, I'm not sure this "issue" warrants an exception either. Still,
debugging problems that arise due to about attempts to assign
protected (and perhaps read-only) attributes seems unnecessarily
difficult to me at present. I think I've learned my lesson by now, but
perhaps this is a good target for framework polishing? I'm happy to
work on a patch if there's agreement on a smart way to approach the
problem.

Thanks for your responses all,
- Trevor

Yeah, I'm not sure this "issue" warrants an exception either. Still,
debugging problems that arise due to about attempts to assign
protected (and perhaps read-only) attributes seems unnecessarily
difficult to me at present. I think I've learned my lesson by now, but
perhaps this is a good target for framework polishing? I'm happy to
work on a patch if there's agreement on a smart way to approach the
problem.

I think the first step might be to prise apart that code so that the
handling of protected attributes is handled in a single method like

def handle_unprotected_attribute_assignment(*attributes)
logger.something
end

You could then override that method with a plugin to aid with
debugging during dev and test.

I'll give this a shot.

Thanks for your reply,
- Trevor

I've attached a patch and example monkey patch over here:

http://rails.lighthouseapp.com/projects/8994-ruby-on-rails/tickets/804-refactor-protected-attribute-assignment-warnings#ticket-804-2

I think this would meet my needs, but it should open up the
possibility for doing other interesting things as well.

Thanks again for your responses all,
- Trevor