Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Convert lack of value to an empty string, not nil. #398

Closed
wants to merge 2 commits into
from

Conversation

Projects
None yet
6 participants
Contributor

homakov commented Jun 4, 2012

Pros:
first - if we send "?admin" query then we are able to make conditions like this:

if params[:admin]
 ...
end

w/ nil we needed to check existance of key using has_key? and that is not nice.

second - we fix some CVE, known and possibly unknown.

Cons:
I don't see anything bad. Seems @tenderlove @steveklabnik don't see either.

Contributor

homakov commented Jun 4, 2012

also slight fix
next unless k || v
weird string, it will never happen. next if p.empty? above will skip iteration if string is empty but if string is not empty k will have some value thus that line is pointless

Member

rkh commented Jun 4, 2012

It would be really cool if you could provide tests with patches. Eases the process a lot.

Contributor

homakov commented Jun 5, 2012

@rkh sure but why to add tests if patch is not accepted yet?
I ask here about acceptance of the change and if you are ready to merge I provide anything.

Member

rkh commented Jun 5, 2012

Right, no, that's two different discussions, really. I see you wanna start a discussion first. A similar question would be: Why write an initial patch if the feature wasn't accepted yet.

@rkh rkh closed this Jun 5, 2012

@rkh rkh reopened this Jun 5, 2012

Contributor

homakov commented Jun 5, 2012

@rkh haha yes :) Sorry, if you haven't noticed, but discussion was kinda started https://twitter.com/steveklabnik/status/208993016134897664 https://twitter.com/tenderlove/status/208991607570182144
Writing the patch is easier than describing how it should work here, this is why. Could you describe why you are against of it?

Member

rkh commented Jun 5, 2012

Right. You have a link to the CVE?

Member

rkh commented Jun 5, 2012

Thanks.

Owner

chneukirchen commented Jun 5, 2012

I disagree. IMO, ?admin should just be accessible with QUERY_STRING, and not result in parameters at all.

But given how it is now, we should be able to differ "foo", "foo=" and "foo=&foo=".

Contributor

homakov commented Jun 5, 2012

@chneukirchen removing from parameters at all definitely not a way to go
why should we differ foo and foo= - we never need nil values and empty string is more comfortable default for developer. GET params are always must be k=v. just "k" is a bug in params and IMO to handle it we should turn it into "k="
also we never differ "foo=&foo=" do we?

Owner

chneukirchen commented Jun 5, 2012

There is a big semantic difference between ?foo (which is from an ISINDEX document) and ?foo= (which is an empty field in a form). And we differ on foo=&foo= which is ["", ""].

(which is an empty field in a form)

This is not necessarily true. Neither is your assertion about what ?foo means. It is technically free-form, though key=value is often used to indicate key/value pairs. See RFC 3986 Sec 3.4 for more.

Owner

chneukirchen commented Jun 5, 2012

Steve Klabnik
reply@reply.github.com
writes:

(which is an empty field in a form)

This is not necessarily true. Neither is your assertion about what ?foo means. It is technically free-form, though key=value is often used to indicate key/value pairs. See RFC 3986 Sec 3.4 for more.

http://web.archive.org/web/20090427173649/http://hoohoo.ncsa.illinois.edu/cgi/forms.html

"The basic procedure is to split the data by the ampersands. Then, for
each name=value pair you get for this, you should URL decode the
name, and then the value, and then do what you like with them."

http://web.archive.org/web/20090427143857/http://hoohoo.ncsa.illinois.edu/cgi/cl.html

"If the server does find a "=" in the QUERY_STRING, then the command
line will not be used, and no decoding will be performed. The query
then remains intact for processing by an appropriate FORM submission
decoder.

Do you know of any case where FORMs are sent without =?

Do you know of any case where FORMs are sent without =?

I meant the opposite; just because it's a key value doesn't mean that it was generated by a form.

Owner

chneukirchen commented Jun 5, 2012

It doesn't have to come from a form, but if you possibly send foo= bar, you'll never send just foo, you send foo=. Thus they should be different.

You don't know that.

Owner

chneukirchen commented Jun 5, 2012

You also don't know that foo= is supposed to mean the same as foo.

Contributor

homakov commented Jun 5, 2012

@chneukirchen leaving it as is is not good, you was agreed in first post, right?
two options:

  1. do not include keys w/o value, ?foo will not create params[:foo] at all.
  2. create something different from nil, obviously empty string.
    if both don't suit let's close it?
Owner

chneukirchen commented Jun 5, 2012

I think it should have been different in first place, but now we got to keep it as it is. Note its the same as in cgi.rb:

% irb -r cgi

CGI.parse("foo")
=> {"foo"=>[]}
CGI.parse("foo=")
=> {"foo"=>[""]}

This pull request passes (merged 1571308 into edc8b92).

Owner

raggi commented Aug 26, 2012

I'll review this again ASAP. I'm concerned that we've gone back and forward over this code for security reasons plenty of times in the past, and the solution doesn't seem to be "interpret the parameters differently", the solution is "write your application code safely".

The last change in this area was made to ensure that parameters round-trip correctly through our existing encoders/decoders. At minimum this commit breaks that.

Whilst I'm considering that we should move away from CGI as a baseline for Rack 2, I'm not so sure that it's the right thing to do today, with Rack 1.x. CGI compliments HTTP (and other RFCs) to provide a more precise set of specifications, although still far from perfect (and far from up to date), the IDB in HTTP (and other RFCs) make all of this very complicated for the wider expanse of users we have.

Please try to remember that our users are not just using Rails/Sinatra on Unicorn/Puma/Mongrel/Thin.

Contributor

homakov commented Aug 26, 2012

@raggi

"interpret the parameters differently", the solution is "write your application code safely".

telling "write code safely" sounds funny to me. is it your only advice? :)

At minimum this commit breaks that

Really "breaks" or just requires some fixes? :)

Owner

raggi commented Nov 2, 2012

References:

6127c81

5c00dd6

c9b4159

There are a few more, many of which were introduced / changed by Josh in 2009.

My largest concern with this is code the presently relies upon having a nil value in these cases. In the rails world, most people will be using blank? or present?, but in the rest of the ruby world, many folks will be using plain conditionals. Due to this I'm hesitant to introduce this any earlier than 1.5, if at all. It's also possible that adding another parse method with these kinds of semantics could be more safe, and Rails could migrate to using that instead.

Contributor

homakov commented Feb 20, 2013

BTW I can close this (marked with milestone?)
Problem was a security concern about find_by_*(nil). But eventually we found a way to send nil with JSON and XML too. Seems I have changed my mind and started to think ''x&y' are both nils. :) Up to you

@raggi raggi closed this Apr 21, 2013

@homakov homakov deleted the unknown repository branch Apr 22, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment