Protecting ActiveRecord Associations

Hi --

Good idea. You'd just have to remember to maintain the whitelist if the
model ever changed. Probably not a big deal, but it would be one more
thing to remember.

One more thing for the automated tests to catch :slight_smile:

Are you familiar with any pattern that only allows nil attributes to be
updated? It seems like that's a closer fit to what some association
protection is trying to accomplish.

You might be able to do something with faux accessors.

-faisal

Hi --

finding most of my belongs_to's need to be protected.

Have you tried attr_accessible? It's sort of the mirror image of
attr_protected -- you provide a whitelist instead of a blacklist.

Good idea. You'd just have to remember to maintain the whitelist if the
model ever changed. Probably not a big deal, but it would be one more
thing to remember. From an aesthetic prospective, I think I'd prefer
the protection rolled up into the association.

I agree about the remembering and aesthetics; it definitely means
you're manually maintaining a kind of parallel configuration on top of
the basic business logic. But keep in mind that it's not just
associations that are vulnerable: someone could also maliciously
insert a change using, say, a class-variable accessor. (Unless this
was tightened up in edge recently? But I don't think so.)

Are you familiar with any pattern that only allows nil attributes to be
updated? It seems like that's a closer fit to what some association
protection is trying to accomplish.

I don't think there's any facility for that at the moment. Maybe one
could write an attr_gateway method, or something, with a block.

David

I agree about the remembering and aesthetics; it definitely means
you're manually maintaining a kind of parallel configuration on top of
the basic business logic. But keep in mind that it's not just
associations that are vulnerable: someone could also maliciously
insert a change using, say, a class-variable accessor. (Unless this
was tightened up in edge recently? But I don't think so.)

This was fixed with some release ago at least for class accessor
defined from within rails itself AFAIK

What I've done to make more strict the mass assignment methods is a
plugin (not published) that just compiles by default attr_accessible
with the actual db attributes of the object, stripping all the foreign
keys.
The plugin offers a facility to add/drop to/from attr_accessible
custom method that you want to make available in mass assignment.
This is quite easy to implement and gives a reasonably safe default to
start from.

Paolo

Hi --

I agree about the remembering and aesthetics; it definitely means
you're manually maintaining a kind of parallel configuration on top of
the basic business logic. But keep in mind that it's not just
associations that are vulnerable: someone could also maliciously
insert a change using, say, a class-variable accessor. (Unless this
was tightened up in edge recently? But I don't think so.)

This was fixed with some release ago at least for class accessor
defined from within rails itself AFAIK

Cool.

What I've done to make more strict the mass assignment methods is a
plugin (not published) that just compiles by default attr_accessible
with the actual db attributes of the object, stripping all the foreign
keys.
The plugin offers a facility to add/drop to/from attr_accessible
custom method that you want to make available in mass assignment.
This is quite easy to implement and gives a reasonably safe default to
start from.

That sounds like a great solution. Are you interested in publishing
the plugin?

David

Hi --

>
>> I agree about the remembering and aesthetics; it definitely means
>> you're manually maintaining a kind of parallel configuration on top of
>> the basic business logic. But keep in mind that it's not just
>> associations that are vulnerable: someone could also maliciously
>> insert a change using, say, a class-variable accessor. (Unless this
>> was tightened up in edge recently? But I don't think so.)
>
> This was fixed with some release ago at least for class accessor
> defined from within rails itself AFAIK

Cool.

> What I've done to make more strict the mass assignment methods is a
> plugin (not published) that just compiles by default attr_accessible
> with the actual db attributes of the object, stripping all the foreign
> keys.
> The plugin offers a facility to add/drop to/from attr_accessible
> custom method that you want to make available in mass assignment.
> This is quite easy to implement and gives a reasonably safe default to
> start from.

That sounds like a great solution. Are you interested in publishing
the plugin?

If I can see there's some interest around it, I might, if I have
permission from my employer and if I've time to arrange to actually
publish it on rubyforge.
But I have to warn it works well only if the app follows AR naming
convention of foreign keys.

Paolo

Hi --

Hi --

I agree about the remembering and aesthetics; it definitely means
you're manually maintaining a kind of parallel configuration on top of
the basic business logic. But keep in mind that it's not just
associations that are vulnerable: someone could also maliciously
insert a change using, say, a class-variable accessor. (Unless this
was tightened up in edge recently? But I don't think so.)

This was fixed with some release ago at least for class accessor
defined from within rails itself AFAIK

Cool.

What I've done to make more strict the mass assignment methods is a
plugin (not published) that just compiles by default attr_accessible
with the actual db attributes of the object, stripping all the foreign
keys.
The plugin offers a facility to add/drop to/from attr_accessible
custom method that you want to make available in mass assignment.
This is quite easy to implement and gives a reasonably safe default to
start from.

That sounds like a great solution. Are you interested in publishing
the plugin?

If I can see there's some interest around it, I might, if I have
permission from my employer and if I've time to arrange to actually
publish it on rubyforge.
But I have to warn it works well only if the app follows AR naming
convention of foreign keys.

You could grab the keys dynamically with reflections or
reflect_on_all_assocations. That might even be easier than
calculating them yourself from table names (if that's what you're
doing).

David

dear sender,
i�m out of the office until may 29th.
your email will not be forwarded.
for urgent stuff please contact joern@fork.de
kind regards,
alexander

Paolo Negri wrote:

What I've done to make more strict the mass assignment methods is a
plugin (not published) that just compiles by default attr_accessible
with the actual db attributes of the object, stripping all the foreign
keys.

The converse would also be helpful: an update_attributes_unsafe method
that allowed unrestricted mass assignment for internal processing,
allowing several separate assignment lines to be compressed into one,
avoiding the puzzlement that can occur when use of update_attributes
for such a multiple assignment fails to work.

Ok, next week I'll be trying to publicly release another project of
mine, but after that I'll seriously look into publishing the plugin so
we can look more in detail on how to improve it.

Paolo