In using both action-args and param-protection, I find each lacking
and feel what is missing needs to pull both into one declaration.
Here's hoping I can start a discussion to find a more complete
solution.
First, I'll state a misgiving about each:
I can use action-args to have something like:
def activate_post(user, _submit_activate, _submit_cancel)
...
..
end
The first param is user which maps nicely to my view's use of form_for
@user and to my other action, activate_get which also uses the same
view.
The second and third params in this case are submit buttons.
Sometimes I do have more than one button on a form. ;)
Unfortunately, this use of action-args, while works well with form_for
and such, doesn't give me any protection as to what attributes of the
user it allows.
If I instead write the above as:
def activate_post(email_confirmation_code, display_name, password,
password_confirm,, _submit_activate, _submit_cancel)
I get better protection but lose my form helper benefits.
Now on to param-protection. This seems to be only controller-wide.
I've tried to use it at an action level and get errors. So maybe I'm
using it wrong. Even if I did have action level param-protection, I
think I would be repeating myself from my specs in action-args.
So is there a way to join them together and also have neat add-ons
like output filtering as well?
How about something like this:
def activate_post
guards Proc { [:user =>
[:email_uncomfirmed, :display_name, :password, :password_confirmed],
:_submit_activate, :_submit_cancel ] }
end
The results of the above is:
1 - wrapper the call to guards in something like a Proc so we can be
"lazy" and only the first time the action is run do we do the magic to
figure things out and do some meta-magic. I'm sure my sketch above is
not the best way to write this ;).
2 - :user implies we want a local var in this method called user. We
will also have local vars _submit_activate and _submit_cancel. Access
to the other params would be by user[:email_unconfirmed], etc...
3 - the default is that anything passed in that doesn't fit is tossed.
How about something more challenging:
def activate_post
guards Proc { [:user => [email_uncomfirmed, display_name, password
=> :in_only, password_confirmed
=> :in_only], :_submit_activate, :_submit_cancel ] }
end
In this case, we mark the two password attribs as something we do not
want to be redisplayed if we re-render the page.
We should be able to come up with a pretty readable, dare I say it,
DSL to add more behavior, like overriding the default behavior if
something doesn't match. Default would be just to throw away
unmatched info. Additional features could be to do param
transformations like specing a param gets converted to a Time or
Integer.
I've seen various message here and on the DM forum about mass
assignment issues. I think the right place to protect your params is
at the front door of each action, not by playing tricks with public
and private Model attributes.
Can someone build on these ideas with me?
This is one of the key areas of "this type of framework" that bugs
me.
I did something like this to great effect but it was in erlang and a
JSON app. But the results were very readable and DRY.
To be certain, I like this idea so much, I'm willing to try to "own
it" and publish an experimental gem but I am out of my depth in
several areas, including finding the correct DSL. I would need
help. ;)
thanks, Jon
http://shellshadow.com
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"merb" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/merb?hl=en
-~----------~----~----~----~------~----~------~--~---
