Ruby on Rails

In this case it is user (hacker, scanner, etc.), not the programmer, who has passed the illegal argument.  I don't think that should result in a 500 server error.  To avoid that, either the programmer has to check each input parameter to make sure it is a string, or something like sanitize has to make the parameter safe.

On Wed, Sep 11, 2013 at 7:21 PM, Robert Walker <li...@ruby-forum.com> wrote:

Paul Lynch wrote in post #1121214:

> If, in your view, you are expecting params[:name] to be a string, but
> actually rails has parsed it into {"."=>"1234"} (or something more
> malicious), then currently
> <%= sanitize(params[:name]) %> blows up because the hash does not
> respond
> the expected methods from the sanitize call.
>
> I could put in code to check that the params values I am sanitizing are
> strings, but it seems like it would be better for sanitize to handle
> that,
> and perhaps just return the empty string if the processing of the input
> raises an exception.

Hum. It seems to me that "blowing up" is the right thing to do in this
scenario. More precisely an exception should be raised indicating a
programmer mistake of passing an illegal argument to a method expecting
a string.

--
Posted via http://www.ruby-forum.com/.

--
You received this message because you are subscribed to a topic in the Google Groups "Ruby on Rails: Talk" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/rubyonrails-talk/6P_vm57_km8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to rubyonrails-ta...@googlegroups.com.
To post to this group, send email to rubyonra...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/c54d51850e1948568b77874beb9f21e1%40ruby-forum.com.

For more options, visit https://groups.google.com/groups/opt_out.

--
Paul Lynch
National Library of Medicine