为什么Rails会不断发回Set-Cookie标头? [英] Why is rails constantly sending back a Set-Cookie header?

查看:114
本文介绍了为什么Rails会不断发回Set-Cookie标头?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我遇到了弹性负载平衡器和清漆缓存方面的问题,这些问题涉及cookie和会话在导轨和客户端之间混杂在一起.问题的一部分是,Rails几乎在每个请求上都添加了带有会话ID的"Set-Cookie"标头.如果客户端已经在发送session_id,并且与rails将要设置的session_id相匹配.为什么Rails会不断告诉客户端哦,是的.您的会话ID是..."

I'm experiencing issues with an elastic load balancer and varnish cache with respect to cookies and sessions getting mixed up between rails and the client. Part of the problem is, rails is adding a "Set-Cookie" header on with a session id on almost every request. If the client already is sending session_id, and it matches the session_id that rails is going to set.. why would rails continuously tell clients "oh yeah.. you're session id is ..."

推荐答案

摘要:几乎在每个响应上都设置了Set-Cookie标头,因为

Summary: Set-Cookie headers are set on almost every response, because

  1. 默认会话存储将根据访问该会话的任何请求(将其读取或写入),尝试将会话数据写入加密的cookie,
  2. 即使纯文本值未加密,加密值也会改变
  3. 加密发生在到达负责检查cookie值是否已更改的代码之前,以避免多余的Set-Cookie标头.
  1. the default session store will try to write the session data to an encrypted cookie on any request that has accessed the session (either to read from it or write to it),
  2. the encrypted value changes even when the plain text value hasn't,
  3. the encryption happens before it reaches the code that's responsible for checking if a cookie value has changed to avoid redundant Set-Cookie headers.


纯文本cookie

在Rails中,ActionDispatch::Cookies中间件负责根据ActionDispatch::Cookies::CookieJar的内容编写Set-Cookie响应头.


Plain-text cookies

In Rails, the ActionDispatch::Cookies middleware is responsible for writing Set-Cookie response headers based on the contents of a ActionDispatch::Cookies::CookieJar.

正常的行为是您所期望的:如果cookie的值与请求的Cookie标头中的值相同,并且有效期未更新,则Rails不会发送新的响应中的Set-Cookie标头.

The normal behaviour is what you'd expect: if a cookie's value hasn't changed from what was in the request's Cookie header, and the expiry date isn't being updated, then Rails won't send a new Set-Cookie header in the response.

这是通过CookieJar#[]=中的条件来解决的,该条件将cookie罐中已存储的值与正在写入的新值进行比较.

This is taken care of by a conditional in CookieJar#[]= which compares the value already stored in the cookie jar against the new value that's being written.

为处理加密的cookie,Rails提供了一个ActionDispatch::Cookies::EncryptedCookieJar类.

To handle encrypted cookies, Rails provides an ActionDispatch::Cookies::EncryptedCookieJar class.

EncryptedCookieJar依靠ActiveSupport::MessageEncryptor提供加密和解密,它使用随机的初始化向量每次调用.这意味着即使给定了相同的纯文本字符串,也几乎可以保证返回不同的加密字符串.换句话说,如果我解密我的会话数据,然后重新加密,我将得到与开始时不同的字符串.

The EncryptedCookieJar relies on ActiveSupport::MessageEncryptor to provide the encryption and decryption, which uses a random initialisation vector every time it's called. This means it's almost guaranteed to return a different encrypted string even when it's given the same plain text string. In other words, if I decrypt my session data, and then re-encrypt it, I'll end up with a different string to the one I started with.

EncryptedCookieJar的作用不大:它包装了常规的CookieJar,并且仅在数据输入时提供加密,而在数据返回时提供解密.这意味着CookieJar#[]=方法仍然负责检查cookie的值是否已更改,甚至不知道其给定的值是否已加密.

The EncryptedCookieJar doesn't do very much: it wraps a regular CookieJar, and just provides encryption as data goes in, and decryption as data comes back out. This means that the CookieJar#[]= method is still responsible for checking if a cookie's value has changed, and it doesn't even know the value it's been given is encrypted.

EncryptedCookieJar的这两个属性说明了为什么在不更改其值的情况下设置加密cookie总是会导致Set-Cookie标头的原因.

These two properties of the EncryptedCookieJar explain why setting an encrypted cookie without changing its value will always result in a Set-Cookie header.

Rails提供了不同的会话存储.它们中的大多数将会话数据存储在服务器上(例如,存储在memcached中),但是默认值ActionDispatch::Session::CookieStore使用EncryptedCookieJar将所有数据存储在加密的cookie中.

Rails provides different session stores. Most of them store the session data on a server (e.g. in memcached), but the default— ActionDispatch::Session::CookieStore—uses EncryptedCookieJar to store all of the data in an encrypted cookie.

ActionDispatch::Session::CookieStore继承了Rack::Session::Abstract::Persisted#commit_session?方法,该方法确定是否应设置cookie.如果会话已加载,那么答案几乎总是是的,设置cookie".

ActionDispatch::Session::CookieStore inherits a #commit_session? method from Rack::Session::Abstract::Persisted, which determines if the cookie should be set. If the session's been loaded, then the answer is pretty much always "yes, set the cookie".

正如我们已经看到的,在会话已加载但未更改的情况下,我们仍将以不同的加密值(因此为Set-Cookie标头)结束.

As we've already seen, in the cases where the session's been loaded but not changed we're still going to end up with a different encrypted value, and therefore a Set-Cookie header.

这篇关于为什么Rails会不断发回Set-Cookie标头?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆