7 ms·
This is probably a best practice you could learn yourself to implement every time you know for sure you don't want a GET/POST variable to be a hash/array. This
by michiel3 14y ago
This is probably a best practice you could learn yourself to implement every time you know for sure you don't want a GET/POST variable to be a hash/array. This can also prevent other application errors when someone passes a hash/array which is used somewhere in the code where it is expected to be a string or something.
- mseebach 14y agoI'm not terribly familiar with the Rails feature in question, but it seems to me that GET/POST params should never be interpreted automatically. Parsing a param into any other type than a string should be explicit.
- tptacek 14y agoYou're (respectfully) not terribly familiar with Rails, then, because the interpretation of foo[bar]=xxx as { :foo => { :bar => 'xxx' } } is one of the core patterns in the framework. Code all across the platform depends on that behavior.
- mseebach 14y agoI get it now. I though there was interpretation of the right hand side of the =.
- sim0n 14y agoThis is the same with PHP. Be aware anyone using something like MongoDB, if you don't sanitize/cast your inputs, your app could be vulnerable. e.g. if you have the code: $collection->findOne( array( 'username' => $_POST['username'], 'password' => $_POST['password'] ) ); someone could POST something like username[$ne]='?'&password[$ne]='?' and login.