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 
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
