使用 HttpCookie 超时/ url 过期答案

【问题标题】：Using HttpCookie for timeout/ url expiration使用 HttpCookie 超时/ url 过期
【发布时间】：2017-10-19 02:15:18
【问题描述】：

我正在开发一个 Web 应用程序，它是 MVC 5 + Angular JS 的混合体。 Web 应用程序中没有无身份验证，匿名用户可以来询问某些服务的价格。为了获得价格，用户需要回答一些分散在几页上的问题。这是应用程序的流程。

用户点击按钮获取价格
生成请求并将用户重定向到问题页面的唯一 URI
用户回答问题，用户提交答案。这些问题分布在通过角度路由导航的多个页面上。答案会在页面导航时保存回服务器。
一旦用户提交答案，系统（服务器）就会生成价格并将其显示给用户。

目前，如果用户已将 URI 加入书签，他可以在几天后返回并从他离开的地方继续。我想阻止这种行为。

在 MVC 中有哪些不同的选项？我可以想到以下几点：

使用带有过期时间的HttpCookie
在数据库中保存上次访问时间并验证用户是否在规定的时间范围内到达？

我想避免HttpSession。我倾向于使用HttpCookie，因为它看起来是最简单的选择。

如果我们使用HttpCookie 选项，我需要记住任何副作用吗？
我可以在 MVC 中寻找其他替代方案吗？

【问题讨论】：

由于您没有登录模块，您也可以选择localStorage，每次都会更新。
如果你不希望用户只从开始访问页面，你可以使用 sessionStorage。一旦用户关闭窗口/选项卡，sessionStorage 将被自动删除，您可以形成用户从头开始。
感谢大家的建议，对于我的场景，我想通过我的 MVC 应用程序/服务器来控制它。 localStorage/ sessionStorage 只是客户端。
为什么要避免HttpSession？它可能比HttpCookie 更适合这种情况。除非您希望用户能够在未来返回到某个点。
我的应用程序将托管在负载平衡环境中。对于HttpSession，我可能不得不进行进程外会话管理。我想避免这种复杂性。另外，最近HttpSession好像不太受宠：brockallen.com/2012/04/07/think-twice-about-using-session-state

标签： c# asp.net angularjs asp.net-mvc session-cookies

【解决方案1】：

如果您想在不涉及存储的情况下使某些链接过期并且您的服务需要扩展，我认为您只需要在链接中添加过期日期并签名即可。

我相信你可以用这样的方式创建你的网址

伪代码：

var info = [Payload any info you need to store(questionnaire id or so)] + [expirationDate]
var sign = HMAC256(info + [SERVER_SECRET])
var clientLinkParameter = info + sign
var clientLink = [baseURL] + [delimiter] + Base64(clientLinkParameter)

*HMAC256 - 这只是一个示例，您可以使用任何您想要的算法创建签名

现在您可以通过解析分隔符之前部分中的序列化数据来检查您的链接是否过期。您还可以通过检查来检查日期是否未被修改：

HMAC256([partBeforeDelimiter] + [SERVER_SECRET]) and [partAfterDelimiter] 表示平等。如果它们匹配，这是您的服务器发送的链接（因为只有您的服务器知道 [SERVER_SECRET] 是什么），否则它被客户端修改。

现在您可以在用户链接中存储任何非机密数据，允许用户共享此链接以及您可以使用链接做的其他很棒的事情，而不必担心有人修改我们的链接。如果其广为人知的序列化算法（如 JSON），客户端也可以反序列化第一部分。

我认为这个流程会在浏览器突然关闭的情况下带来更好的用户体验（这将在您的情况下清除 cookie）并与某人共享链接（如果您需要）

希望这会有所帮助。

【讨论】：

这确实是一个不错的方法。但是，我现在已经使用会话 cookie。如果我将来需要类似的东西，会考虑这个。

【解决方案2】：

最后，我选择了 session-cookie。我对唯一 ID 进行哈希处理，并用盐将其保存在 cookie 中。我觉得这是一个合理的方法，原因如下：

匿名用户会话将是短暂的。有一次，他关闭了浏览器，cookie 被删除。
如果用户为 URI 添加书签，我会在 Http Request 中查找 session-cookie。如果找不到会话 cookie，我会将用户重定向到挑战页面。

我已经使用 MD5 算法进行散列。我知道它容易发生碰撞，但比 SHA 快。由于我没有在cookie中存储密码等敏感信息，我想应该没问题。

【讨论】：

【解决方案3】：

我宁愿为唯一的用户会话生成一个令牌，并将其与 CreatedDate 一起存储在服务器上。因此 URL 将具有一个令牌查询字符串参数，该参数将根据日期进行验证。

比依靠 cookie 更安全
允许向您的站点添加分析，您可以在其中开始存储 q/a 组合以及为给定用户会话生成的价格。尽早开始收集数据。 :)

【讨论】：