ruby-on-rails - 如何在 Rails 中禁用 cookie 的 URL 编码

Question

我有一个 Rails 应用程序，它必须与一个非常旧的遗留应用程序共存。旧应用程序会查找其值包含特定字符串的 cookie。不幸的是，传统 cookie 中的字符通常包含斜杠。我遇到的问题是，当 Rails 应用程序写入 cookie 时，它​​首先进行 URL 编码，这会导致旧应用程序崩溃，因为 cookie 值不正确。

我通过编辑文件cookie_performance_fix.rb(路径:./actionpack-1.13.5/lib/action_controller/cgi_ext/cookie_performance_fix.rb)
为了使其正常工作，我更改了代码，如下所示:

def to_s
  buf = ""
  buf << @name << '='

  if @value.kind_of?(String)
    rails code. 
        #buf << CGI::escape(@value)
         buf << @value
  else
        #buf << @value.collect{|v| CGI::escape(v) }.join("&")
    buf << @value.collect{|v| (v) }.join("&")

  end

这实际上工作得很好，直到我决定将 Rails 升级到版本 2.3.2
在 Rails 2.3.2 中，cookie_performance_fix.rb 文件不再存在。我查看了同一目录，发现了一个名为 cookie.rb 的文件，我尝试以类似的方式对其进行修改。

def to_s
  buf = ''
  buf << @name << '='
  #buf << (@value.kind_of?(String) ? CGI::escape(@value) : @value.collect{|v| CGI::escape(v) }.join("&"))
    buf << (@value.kind_of?(String) ? @value : @value.collect{|v| (v) }.join("&"))
  buf << '; domain=' << @domain if @domain
  buf << '; path=' << @path if @path
  buf << '; expires=' << CGI::rfc1123_date(@expires) if @expires
  buf << '; secure' if @secure
  buf << '; HttpOnly' if @http_only
  buf
end

不幸的是，这似乎不起作用。在新的 Rails 2.3.2 中，cookie 不断进行 URL 编码。我知道关闭 URL 编码不是最好的主意，但在遗留应用程序退役之前我没有太多选择。遗憾的是，我无法访问旧代码来添加对 cookie 进行 URL 取消编码的支持，因此我必须确保旧 cookie 的写入顺序正确，包括斜杠。如果有人能告诉我如何在 Rails 2.3.2 中关闭 URL 编码，我将不胜感激。
谢谢。

Answer 1

经过一番挖掘后，我找到了问题的答案，并将其记录在此处，以防对其他人有用。

为了关闭 Rails 2.3.2 中的 URL 编码，需要编辑以下文件:actionpack-2.3.2/lib/action_controller/vendor/rack-1.0/rack/response.rb

在第 70 行左右，设置了 cookie 的 ID 和值。我对 URL 编码进行了以下更改:

cookie = Utils.escape(key) + "=" +
    #value.map { |v| Utils.escape v }.join("&") +
    value.map { |v| v }.join("&") +
    "#{domain}#{path}#{expires}#{secure}#{httponly}"

注意:此修改仅影响标准 cookie，而不影响版本 2.3.2 中 Rails 用作 session 数据的 cookie。

免责声明:我绝不建议将此修改作为最佳实践。此修改仅是出于处理遗留代码要求(要求 cookie 采用特定格式)的特定原因而进行的。更好的选择甚至是修改遗留代码来处理 URL 编码。不幸的是，这个选项对我来说是关闭的，所以我被迫修改底层的 Rails 代码 - 这不是我通常推荐的。当然，不言而喻，进行此类修改会带来风险，即每次升级 Rails 安装时都必须重新解决该问题，因为底层代码可能会发生变化。这就是我的案例中实际发生的情况。当然，如果可能的话，也可能有充分的理由(安全性、标准合规性等)来保持 URL 编码。