Mass assignment is a fairly normal thing to do, any parameters you want the model to ignore can be marked as so in the model and then mass assignment will work anywhere. Rails loves DRY.
Since the only way in which one can get wrong arguments is if somebody is hacking you (or attempting to do so) in which case just throwing an error at them is a fair thing to do.
Most likely, their native client is blindly adding the objective c properties to the POST request, by using introspection. Apple is not adding anything to the POST request. This is similar to the problems people used to run into when the javascript object prototype was overridden and everyone's code would break because they were just doing
I'm sure this is what's happening. Their serializer is perhaps filtering out properties they knew about, but shouldGroupAccessibilityChildren is a new property on the UIAccessibility Protocol which is adopted by NSObject.
A good short-term fix is to update the web service, but they should update it to only use the POST parameters it expects. When they release an update to the iOS app, they can fix their serializer to only serialize the properties they need.
Yeah, the discussion here seems to be missing the forest for the trees.
For non-Rails programmers an idea such as mass assignment sounds very strange, but if you ignore that, it still sounds odd at first request than an OS would inject parameters into a HTTP post request.
These folks are claiming that this is an issue without creating a minimal program that reproduces the issue. If it were a real issue it would be trivial to make an app that POSTs to an API and inspect the traffic.
I have inspected several POST requests from iOS 6 apps and have not seen anything like this yet.
Will this be a default in Rails 4? I feel like people should need to go through a lot of work to do something as dangerous as Rails/AR mass assignment...
I'm amazed at how the discussion here has devolved into the merits of mass assignment. While that is a worthwhile topic in itself, specially given the recent github issues, any suggestion that the this issue would have been mitigated by the OP not using mass assignment is flawed.
Any webapp that I would consider secure MUST validate all input from clients. This includes white listing any and all parameters names, preferably in middleware, but at least in the controller. Allowing random keys in your input seems recipe for disaster, when you consider a multi layer app security policy. While this may seem like an overkill to some, this is best practice I've seen implemented in any project that deals with real money.
Hence, such a change in iOS WILL break any such application. Irrespective of your views on the sanity of mass assignment.
I would like to see a discussion on why apple thought it would be a good idea to introduce a new parameter to every request. Any ideas?
"Validating input" can yield a number of results, and ignoring incorrect data (keys) altogether is not only a valid reaction, it's a perfectly safe one and it's how the vast majority of systems work. Indeed, a number of usual patterns would break if that didn't work.
Mass-assignment and similar patterns (of shoving all request parameters into your trusted content, see also `extract` and `register_globals`) "allow random keys into your input", ignoring said keys doesn't.
[+] [-] ubernostrum|13 years ago|reply
1. They were blindly throwing the entire set of POST data into a Rails model.
2. This started throwing errors when they got an unexpected key in POST.
3. They "solved" the problem by writing a middleware to filter out that specific key from POST.
I don't even know where to begin.
[+] [-] tomjen3|13 years ago|reply
Mass assignment is a fairly normal thing to do, any parameters you want the model to ignore can be marked as so in the model and then mass assignment will work anywhere. Rails loves DRY.
Since the only way in which one can get wrong arguments is if somebody is hacking you (or attempting to do so) in which case just throwing an error at them is a fair thing to do.
[+] [-] kalleboo|13 years ago|reply
[+] [-] jmcnevin|13 years ago|reply
[+] [-] est|13 years ago|reply
Watch next time Apple alter some http headers and break your API.
[+] [-] mobwill|13 years ago|reply
for (var prop in object)
[+] [-] jcromartie|13 years ago|reply
http://developer.apple.com/library/ios/documentation/uikit/r...
[+] [-] lancefisher|13 years ago|reply
A good short-term fix is to update the web service, but they should update it to only use the POST parameters it expects. When they release an update to the iOS app, they can fix their serializer to only serialize the properties they need.
Apple isn't injecting this - their code is.
[+] [-] ejs|13 years ago|reply
If you do something like:
@user = User.new(params[:user].slice(:name))
It will be safer, and avoid the problem.
[+] [-] eli|13 years ago|reply
It's weird that iOS is doing that... but (at the risk of piling on) browsers do all sorts of weird stuff. Your app needs to deal with it.
[+] [-] brown9-2|13 years ago|reply
For non-Rails programmers an idea such as mass assignment sounds very strange, but if you ignore that, it still sounds odd at first request than an OS would inject parameters into a HTTP post request.
[+] [-] jcromartie|13 years ago|reply
I have inspected several POST requests from iOS 6 apps and have not seen anything like this yet.
[+] [-] tilsammans|13 years ago|reply
[+] [-] jcromartie|13 years ago|reply
[+] [-] asg|13 years ago|reply
Any webapp that I would consider secure MUST validate all input from clients. This includes white listing any and all parameters names, preferably in middleware, but at least in the controller. Allowing random keys in your input seems recipe for disaster, when you consider a multi layer app security policy. While this may seem like an overkill to some, this is best practice I've seen implemented in any project that deals with real money.
Hence, such a change in iOS WILL break any such application. Irrespective of your views on the sanity of mass assignment.
I would like to see a discussion on why apple thought it would be a good idea to introduce a new parameter to every request. Any ideas?
[+] [-] masklinn|13 years ago|reply
Mass-assignment and similar patterns (of shoving all request parameters into your trusted content, see also `extract` and `register_globals`) "allow random keys into your input", ignoring said keys doesn't.