Rails with Rack 1.4.1 and malformed cookies; advice needed

Rails
1

I’m looking for advice as to the best way to handle a bug in Rack 1.4.1.
The bug has been fixed upstream, but Rack ~> 1.4.0 is the requirement
for
Rails stable right now, which will mean 1.4.1. Rack HEAD causes a
warning
message to be displayed when using the cookie session store, which is
something being actively worked on.

The rack bug dealing with malformed cookies:

Talk about Rack HEAD and the rails cookie store:

ActionDispatch::Session::CookieStore not subclassing
Rack::Session::Cookie
seems like a great approach. So, both of these issues are being worked
on
in great ways, or are already solved.

Our rails apps are mostly installed on sub-domains of a large public
university domain. We offer an ezproxy service which makes licensed
campus
services available to users off-campus. One of those services
(lynda.com)
sets a malformed cookie (ending in ,:wink: which triggers the bug in Rack
1.4.1
detailed in the rack issue #386. Because this service can sometimes run
through a proxy service on our domain, and the vendor specifies this
cookie
as a root domain level cookie, the cookie gets set and is then sent for
all
apps on the domain, including our rails apps running on sub-domains.
This
situation is admittedly not ideal. Neither setting a domain level cookie
for this purpose, or setting a malformed cookie, are good practices.
But,
they are practices I have absolutely no control over. Also, being part
of
such a large eco-system means there are numerous cookie practices I have
no
control over as an application developer.

The malformed cookie bug essentially means, any site on our domain can
very
easily cause my app to throw a 500 application wide, by simply setting a
domain level malformed cookie. We have sites running on our domain
written
in every language and web framework I’ve ever heard of. I’ve been trying
to
advocate Rails usage, because I love rails, and am wanting to move some
fairly important sites (at least to us) to Rails, so I’m trying to
figure
out the most reliable way to patch this for production sites using (as
of
this writing) rails 3.2.9.

The two options I’ve considered are:

  1. Forking Rack, branching from the 1.4.1 tag, and cherry picking the
    commit that got merged in from issue 386, and putting gem ‘rack’, :git
    =>
    ‘my_repo’, :branch => ‘1.4.1-backports’ in my Gemfile.
  2. Pointing my Gemfile to rack’s git repo, using some branch or commit
    on
    Master, and either dealing with the rails issue #7372 until it’s fixed,
    or
    passing a :secret into the cookie session store, even though I know
    action
    dispatch wont use it, but will rather use
    “action_dispatch.secret_token.”
    This is only a problem for apps using the cookie session store.

I’ve opted for option #1 for now.

The bigger issue for me is that sites created by installing rails as of
today, with gem install rails, will create rails sites that I know will
be
broken for users that simply view lynda.com videos using our ezproxy
service, which isn’t all that uncommon. I discovered this by asking 5
people to test a new application we’re getting ready to launch. One of
the
five told me it threw a 500 error, and caused me to start digging into
all
of this. As someone who’s trying to advocate rails usage, it may be a
harder sell now that I feel I need to tell people that gem install rails
will not create a fully viable environment for us. I navigated that path
today, got the cookie set, and now 3 of the sites I’ve launched recently
throw 500 for me.

Sorry for the long message. I’m mostly looking for advice regarding the
safest, most reliable, and least obtrusive way of getting a patched
version
of Rack into my rails 3.2.9 projects. I’ll have to figure out a way to
communicate this necessity to users interested in getting into Rails.

Thanks,

  • Bryan