我注意到我们的代码以 cookie 的形式将访问令牌/授权令牌添加到响应中，使用
((HttpServletResponse) response).addCookie(accessTokenCookie);
我做了一些研究并发现了以下信息：
请求cookies是从浏览器发送到服务器的cookies
响应cookies是发送出去的cookies（从服务器到浏览器）。
如果是这种情况，我的请求拦截器/doFilterInternal 是否需要在请求通过之前将访问令牌 cookie 应用于请求，而不是响应？
更令人困惑的是，访问令牌 cookie 是通过使用 request.getAttribute 获取访问令牌值来创建的。如果请求已经有访问令牌作为属性，为什么还要在响应中添加cookie？
【问题讨论】：
标签： java cookies request token interceptor
您误解了 cookie 的工作原理。
浏览器向某个服务器上的某个资源发送请求。
服务器返回构成资源的字节。
这是基本流程。现在，让我们谈谈 cookie：
当服务器返回这些字节时，它可以连同它一起发送标头。实际上是必需的；例如，谈论数据代表什么。例如，如果您请求/img/background.png，则服务器返回图像数据并同时发送Content-Type: image/png。因为浏览器实际上并没有完成整个“扩展指示数据是什么”的事情，这就是 Content-Type 标头的用途。
其中一个标头是 Set-Cookie 标头。
Set-Cookie 标头告诉浏览器：获取此数据并将其保存在某处。下次加载此资源时，请再次发送。有一些关于何时发送它的控制（您可以在服务器响应请求 /foo/bar 时发送 Set-Cookie 标头，使浏览器即使在请求 /foo/baz 时也发送回该 cookie，或者例如当 foo.myserver.com发送一个 cookie，它可以告诉浏览器：当从 bar.myserver.com 请求资源时也将它发送回来。但是有限制；在响应 myserver.com 上的请求时设置 cookie 时，你不能告诉浏览器发送发送到google.com 时返回。浏览器是复杂的野兽；它们附带大量顶级域列表，不会让您这样做。
您不会向“请求”“添加”cookie - 请求内容（您可以从HttpServletRequest 对象获得的数据）只是代表浏览器向服务器发送的内容。 HttpServletRequest/Response 的模型严格来说是两个阶段：浏览器发送请求，服务器响应。而已。这不是一个很长的谈话。每种方式只有一条消息，这就是您得到的全部信息。
因此，您将 cookie 添加到“响应”，这意味着同一浏览器发出的未来请求将在“请求”中发送。
【讨论】：