Why the Latest Rails Exploit Is Indicative of a Bigger Problem

Post by alinajaf » Sat, Feb 16, 2013, 6:39 PM UTC

sanderjd wrote: post #50

alinajaf wrote: post #47

Earlier quoted context omitted.

> Yes. When you write a controller action, you have access to what appears to be a hash called `params`, which is a representation of the parameters that the user passed in their request. It could be GET query parameters, or POST parameter data, or a parsed representation of JSON data. So in ActionController::Metal (a superclass of ActionController::Base) you have: def params @_params ||= request.params end which is…

A few things. The condescending attitude is not necessary. I never claimed that it is somehow impossible or prohibitively difficult to determine how things in Rails work - it is very possible and I do it myself all the time. What I claimed is that Rails has chosen abstraction over obviousness, and gave an example of a place where I believe that is demonstrated. People usually inherit from AC::Base, not AC::Metal, whi…

How exactly would you parse parameters in a web application framework differently?

Post by sanderjd » Sun, Feb 17, 2013, 5:33 PM UTC

alinajaf wrote: post #51

sanderjd wrote: post #50

Earlier quoted context omitted.

A few things. The condescending attitude is not necessary. I never claimed that it is somehow impossible or prohibitively difficult to determine how things in Rails work - it is very possible and I do it myself all the time. What I claimed is that Rails has chosen abstraction over obviousness, and gave an example of a place where I believe that is demonstrated. People usually inherit from AC::Base, not AC::Metal, whi…

How exactly would you parse parameters in a web application framework differently?

As always in software, there are lots of options. Here are two:

1. Provide the action with the raw request body as a string. It is then solely responsible for any and all parsing.

2. Provide the action with the raw request body as a string, but provide standard parsing classes that the action can use depending on what they are specifically doing.

Both of those solutions would make the parsing code less abstract than the Rails solution, with different trade-offs.

I believe this entire thread started because I claimed that Rails has chosen to be further toward the abstraction side of the scale. I can't tell if you really think I am wrong about that, or if you merely think that the choice Rails has made is the right one. If it's the latter, I agree with you, and never claimed otherwise. But it is a choice, and it has trade-offs.

Re: Why the Latest Rails Exploit Is Indicative of a Bigger Problem

Re: Why the Latest Rails Exploit Is Indicative of a Bigger Problem