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: https://github.com/rack/rack/issues/386 Talk about Rack HEAD and the rails cookie store: https://github.com/rails/rails/issues/7372 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 ,;) 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 -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msg/rubyonrails-talk/-/F3RQpBXg52AJ. For more options, visit https://groups.google.com/groups/opt_out.
