HTTP_COOKIE IIS 服务器变量因未知原因到期答案

【问题标题】：HTTP_COOKIE IIS Server Variable expiring for unknown reasonHTTP_COOKIE IIS 服务器变量因未知原因到期
【发布时间】：2016-04-07 21:39:26
【问题描述】：

简短说明：IIS 服务器变量“HTTP_COOKIE”的到期时间似乎不受任何超时变量的控制，我想知道是什么原因造成的。我已经尝试修改在 IIS 中可以看到的所有超时/到期控制值，但在大约 20-30 分钟内没有任何变化。

详情：

我们有一个带有 C++ 后端的应用程序，它使用 IIS 服务器变量“HTTP_COOKIE”来存储状态数据，最重要的是该用户当前会话的会话 ID（GUID，用于问题的其余部分）。要求任何用户只能登录一次，并且 GUID 是用于强制执行此操作的数据之一 - 每次用户登录时，都会刷新 GUID。每次用户完成一项操作时，都会根据最近为该用户创建的 GUID 检查本地存储在选项卡 sessionStorage 中的 GUID（即用户首次登录该选项卡时的值）。如果它们不匹配，用户将被踢出该选项卡上的应用程序。

现在，问题在于有两种情况会刷新 GUID：当用户登录时，以及当应用程序无法在其内存中找到现有 GUID 或 HTTP_COOKIE 字符串时。案例 1 很好——这就是我们想要的。情况 2 很烦人，因为 IIS 设置中似乎有一些东西导致 HTTP_COOKIE 在 20-30 分钟后被清除（我还没有确定它到底有多长）。我们看了看，我们发现很多超时可能会导致这种情况，但是将每个超时修改为 1 分钟，重置 IIS 并再次尝试对超时没有影响： p>

站点=>默认网站=>会话状态=>Cookie 设置=>超时
站点=>默认网站=>ASP=>会话属性=>超时
站点=>默认网站=>Allstate 应用程序=>ASP=>会话属性=>超时

确实有所作为的唯一因素是：

应用程序池 => 高级设置 => 进程模型 => 空闲超时

但这是因为它在另一个超时之前开始并重置所有内容，而不是它是导致我们想要删除的那个的原因。在我们的系统中，此超时通常被禁用（根据 MSDN 指南设置为 0 分钟）。

我已经浏览了我能想到的所有内容 - 这绝对是一个 IIS 问题，因为无论是否过期，服务器端代码都在执行完全相同的任务，唯一的区别是 HTTP_COOKIE 字符串在上面之后消失了空闲时间，因此它会生成一个新的 GUID，因为它找不到现有的 GUID。事件日志中没有错误表明某些内容已用完空间或以其他方式失败导致重置。

我要问的是是否有人知道其他可以控制它的东西，以及在哪里可以禁用/修改为更大的值。如果您知道这是什么并且知道它是不可能绕过的，那么知道这也是有用的。如果是这种情况，如果有人对存储用户会话的 GUID 的更好方法提出建议，他们也将不胜感激！

提前致谢。

附：如果涉及到系统的完全重写，我并不是在寻找更好的方法来处理这个问题 - 现有的系统过于复杂，但应用程序已经过时（约 15 年）并且包含许多我们正在使用的过时方法没有资源来整理，所以我唯一的选择就是按原样使用系统。

【问题讨论】：

来吧人们！有人肯定知道一些事情！
生成 cookie 的服务器上的代码是什么样的？听起来cookie只是在客户端过期，此时客户端将停止在后续请求中发送它......
客户端上的 cookie 很可能会过期（这几乎可以肯定是通过某种方法发生的，无论是 cookie 本身还是会话），问题是为什么。据我所知，我们已经涵盖了我们可以找到的每个超时或默认到期时间，我正在寻找的是导致它（cookie 或会话，无论它是什么）在 20-30 分钟后到期的确切原因
如果您正在检查 cookie 中的 GUID 值，那么必须在某个时候将该 GUID 值放入 cookie 中。生成 cookie 的应用程序中的代码是什么样的？例如，它是否包括到期时间？
在这种情况下，代码不会有太大帮助 - cookie 字符串（包括 GUID）被生成，然后使用 HSE_REQ_SEND_RESPONSE_HEADER_EX 支持函数发送到 IIS 请求。然后数据一直保留在那里，直到它被我们无法放置的超时/到期神秘地清除，这就是我正在寻找答案的地方。 cookie 中没有包含到期时间，根据 IIS 文档，这意味着它应该使用默认值，即会话到期/结束，这应该是选项卡的关闭。我现在正在运行测试，手动定义 cookie 过期时间

标签： asp.net session iis server-variables

【解决方案1】：

HTTP_COOKIE 只是通过请求/响应标头传递的连接字符串，用于存储在客户端上的该域的所有 valid cookie。您基本上会受到会话 ID 的默认超时的影响。只需创建您自己的会话标识符（例如，生成存储在数据库表中的 GUID）并让客户端将其存储为具有不同到期日期的 cookie。使用每个有效的用户交互更新到期日期以延长会话。问题解决了。

【讨论】：

“会话 ID 的默认超时”是什么意思？这是在 IIS 中设置的值吗？到目前为止，我所读到的所有内容都暗示会话将在选项卡/浏览器的生命周期内持续存在，并且 cookie 应该默认在会话结束时过期。为了使您所说的有效，这些事情都不必是真的。
存在一个根本性的误解。 HTTP 是一个完全无状态的协议，因此创建会话的东西是持久的，可以识别来自同一浏览器的最近活动，这基本上是在服务器上生成并存储在客户端上的唯一会话标识符。 IIS 服务器无法知道用户何时仍处于活动状态，只能通过将上次交互时间与当前时间进行比较来“假设”他已经离开。如果超过 X 分钟，则 IIS 将会话称为“过期”。（下文续）
由于您使用自己的 ISAPI 扩展，基本上由您的应用程序来管理会话超时，方法是检查和更新用于跟踪每次交互的会话 ID 的 cookie。如果您使用的是 ASP，它本身就是一个 ISAPI DLL，那么超时将是 ASPSESSIONID cookie 的生命周期，默认设置为 20 分钟。使用 cookie，如果您没有设置特定的生命周期，浏览器将在关闭时将其丢弃。但是，这不会在服务器上触发事件，因此服务器不会知道选项卡/浏览器何时关闭。（下文续）
因此，如果在上次连接发生后的 20 分钟内没有收到任何交互，服务器将重新发出带有新会话标识符的新 cookie。现在，如果在您自己的 ISAPI 应用程序中，您想保持更长的会话，那么您需要：1) 确定会话应该多长时间，2) 在客户端上存储您自己的 SessionID cookie，并将其到期日期设置为 (当前时间+超时），3）如果在请求标头上拾取相同的cookie，则在每次交互时检查并使用（当前时间+超时）更新相同的cookie。（下文续）
如果您收到的请求没有特定的 SessionID cookie，则 cookie 已经过期，或者浏览器没有发送它。您唯一的选择是假设这是一个新客户端并重新发出一个新的 SessionID cookie。（下文续）

【解决方案2】：

您确定会话 cookie 即将过期并且问题在所有浏览器中都一致吗？

我遇到了一些问题，即应用程序出现致命错误或服务器上的内存已满，AppPool 崩溃，因此会话自行重置。请在此期间使用 Perfmon 监控服务器日志，可能会出现一些致命错误、应用程序错误、IIS 错误或系统错误。

我已经像这样挣扎了很长时间，最后 cultprit 是致命错误，由于有时 AppPool 崩溃，因此使用该 AppPool 托管在 IIS 上的所有应用程序也会重置，因此这些应用程序的会话被破坏。

【讨论】：

不幸的是，我们想到了这一点 - 没有内存问题或崩溃 - 事件日志没有显示与到期时间一致的异常情况。同样不幸的是，我们无法在 IE 以外的任何浏览器中测试该问题 - 原作者认为跨浏览器兼容性早在 1993 年就不是问题，并且代码中充满了 IE 特定的代码。