使用HttpCookie进行超时/ url到期

I'm working a web application, which is MVC 5 + Angular JS hybrid. There is no authentication in the web app and an anonymous user can come and ask for price for certain services. To get the price the user needs to answer some questions spread across few pages. Here is the flow of app.

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

User clicks button to get price

用户点击按钮获取价格
A unique URI the request is generated and user is redirect to the questions page

生成请求的唯一URI,用户将重定向到问题页面
User answers questions and user submits the answers. The questions are spread across multiple pages navigated through angular routing. The answers are saved back to server on page navigation.

用户回答问题,用户提交答案。问题分布在通过角度路由导航的多个页面上。答案将在页面导航中保存回服务器。
Once, the user submits the answers, the system (server) generate the price and display it to user.

一旦用户提交答案,系统(服务器)就会生成价格并将其显示给用户。

Currently, if the user has bookmarked the URI, he can come back after days and continue from where he left. I want to prevent this behaviour.

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

What are the different options do I have in MVC? I can think of following:

我在MVC中有哪些不同的选择?我可以想到以下几点:

Using HttpCookie with expiration time

使用带有过期时间的HttpCookie
Save the last access time in DB and validate if the user has come within a stipulated time frame?

保存数据库中的最后访问时间并验证用户是否已达到规定的时间范围内?

I would like to avoid HttpSession. I'm inclined towards using HttpCookie since it looks to be the simplest option.

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

If we go with HttpCookie option, are there any side effect that I need to keep in mind?

如果我们选择HttpCookie选项,是否有任何副作用,我需要记住?
Are there any other alternative within MVC I can look for?

我可以在MVC中找到其他替代方案吗?

3 个解决方案

#1

If You want to expire some link without storage involved and your service need to be scaled I think You just need to add expiration date in your link and sign it.

如果您希望在没有存储空间的情况下使某些链接过期,并且您的服务需要缩放,我认为您只需要在链接中添加过期日期并签名即可。

I believe you can create your URL in a way like this

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

Pseudocode:

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 - it's just example you can create signature using any algorithm you want

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

Now you can just check your link for expiration by parsing serialized data in the part before delimiter. You can also check that date was not modified by checking:

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

HMAC256([partBeforeDelimiter] + [SERVER_SECRET]) and [partAfterDelimiter] for equality. If they match this is the link your server sent (as only your servers know what the [SERVER_SECRET] is) otherwise it was modified by the client.

HMAC256([partBeforeDelimiter] + [SERVER_SECRET])和[partAfterDelimiter]用于相等。如果它们匹配,则这是您的服务器发送的链接(因为只有您的服务器知道[SERVER_SECRET]是什么),否则它被客户端修改。

Now you can store any non secret data in user link allow user to share this link and other great things that you can do with a link without worrying that someone modify our link. Client can deserialize first part as well if its widely known serialization algorithm like JSON.

现在,您可以将任何非机密数据存储在用户链接中,允许用户共享此链接以及您可以使用链接执行的其他重要操作,而无需担心有人修改我们的链接。如果广泛知道的序列化算法如JSON,客户端也可以反序列化第一部分。

I think this flow will bring better user experience in case of suddenly closed browser (that will clean cookies in your case) and also sharing link with someone (if you need)

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

Hope this will help.

希望这会有所帮助。

#2

I finally, went with session-cookie. I hashed the unique id and saved it in the cookie with salt. I feel this is a reasonable approach for following reasons:

我终于和session-cookie一起去了。我将唯一的ID哈希并用盐保存在cookie中。我觉得这是一个合理的方法,原因如下:

The anonymous user session is going to be short lived. Once, he closes the browser the cookie gets removed.

匿名用户会话将是短暂的。有一次,他关闭了浏览器,删除了cookie。
If the user bookmarks the URI, I look for session-cookie in the Http Request. If the session cookie is not found, I redirect the user to the challenge page.

如果用户为URI添加了书签,我会在Http请求中查找会话cookie。如果找不到会话cookie,我会将用户重定向到挑战页面。

I have gone for MD5 algorithm for hashing. I understand it is collision prone, but is faster than SHA. Since I do not store sensitive information like password in the cookie, I guess it should be fine.

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

#3

I'd rather generate a token for a unique user session and store it on the server along with CreatedDate. So URL will have a token query string parameter that will be validated against the date.

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

It's more secure than relying on cookies

它比依赖cookie更安全

Allows for adding analytics to your site, where you start storing q/a combinations along with generated prices for a given user session. Start collecting data early. :)

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

#1