Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

Rack::Session::Cookie does not handle a nil cookie string #223

Closed
ajsharp opened this Issue · 15 comments
@ajsharp

We've observed this behavior with rack 1.2.3, but glancing at the same code on HEAD, this bug likely still exists. The offending code is the following:

def generate_hmac(data)
  OpenSSL::HMAC.hexdigest(OpenSSL::Digest::SHA1.new, @secret, data)
end

When data is nil, the hexdigest method raises the following exception: TypeError: can't convert nil into String.

Here is the cookie string causing this error:

_utmarr=4e4ddd2d633fe81454000001; path=/; expires=Tue, 18-Oct-2011 03:49:03 GMT, rack.session=; path=/; expires=Thu, 01-Jan-1970 00:00:00 GMT
@raggi
Owner

this appears to work fine against master, unless i'm being stupid. If you can give me a replication case, I'll be happy to fix it. Thanks!

@raggi raggi closed this
@tlianza

I still see this issue with rack 1.4.0 with a Sinatra app:

TypeError - can't convert nil into String:
/app/.bundle/gems/ruby/1.8/gems/rack-1.4.0/lib/rack/session/cookie.rb:152:in `generate_hmac'
/app/.bundle/gems/ruby/1.8/gems/rack-1.4.0/lib/rack/session/cookie.rb:152:in `hexdigest'
/app/.bundle/gems/ruby/1.8/gems/rack-1.4.0/lib/rack/session/cookie.rb:109:in `unpacked_cookie_data'
/app/.bundle/gems/ruby/1.8/gems/rack-1.4.0/lib/rack/session/cookie.rb:93:in `load_session'
/app/.bundle/gems/ruby/1.8/gems/rack-1.4.0/lib/rack/session/abstract/id.rb:130:in `send'
/app/.bundle/gems/ruby/1.8/gems/rack-1.4.0/lib/rack/session/abstract/id.rb:130:in `load!'
/app/.bundle/gems/ruby/1.8/gems/rack-1.4.0/lib/rack/session/abstract/id.rb:126:in `load_for_write!'
./default.rb:85:in `before (?-mix:)'
/app/.bundle/gems/ruby/1.8/gems/sinatra-1.3.1/lib/sinatra/base.rb:1211:in `call'

@metasoarous

I'm seeing this issue with Rack 1.4.0 and a Sinatra app as well.

@rwilcox

+1 - I'm also seeing this issue. Rack 1.4, Sinatra app + Ruby 1.9.2

@hlascelles

I'm seeing this issue when running two servers (Padrino) on different ports. Importantly, they have different session secrets.

If I delete the sessions cookies for localhost, the first (either) of the servers I hit works fine, but when I hit the other it fails.

@rwilcox

In my particular case I moved to using Rack::Session::Cookie directly, and specifying the secret and the domain. Then it worked.

(I'm also using a cluster of thins, and @hlascelles 's hint pushed me in that direction)

@benrady

Also seeing this problem with Rack 1.4.0 (and Sinatra 1.3.2)

Here's my app:

require 'sinatra/base'

class Bug < Sinatra::Base
  enable :sessions
  get '/' do
    session.inspect
  end
end

And here's my rackup file

$LOAD_PATH << File.join(Dir.getwd)

require 'bug'

run Bug

I'm using thin, so I run it like this:

$ thin start -R bug.ru

Note that you have to start the server, load the page, restart the server, and then load the page again to reproduce this problem. This makes it impossible to use reloading tools like shotgun.

@hlascelles

This appears to have been fixed (for my situation of conflicting cookie secrets using Padrino) by the change supplied for 299 on master.

ie, using the following in your gemfile should fix it

gem 'rack', '1.4.0', :git =>  "git://github.com/rack/rack.git" 
@noxoc

Had the same Issue (on heroku) and gem 'rack', '1.4.0', :git => "git://github.com/rack/rack.git" fixed it for me too.

@maxpert
 gem 'rack', '1.4.0', :git =>  "git://github.com/rack/rack.git" 

Worked for me too. I think rack have some fixing to do.

@muccy

Heroku crashes if I use your quick fix:
/usr/ruby1.9.2/lib/ruby/1.9.1/rubygems.rb:762:in `report_activate_error': RubyGem version error: rack(1.1.0 not ~> 1.3, >= 1.3.6) (Gem::LoadError)

I think it's because Sinatra requires rack ~> 1.3

@julik

I hope there might be a bugfix release for this. Say, 1.4.1

@tkellen

+10000

@rdetert

Ruby frameworks tend to have a lot of cookie bugs. +1 on a fixed gem.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.