0

Scenario

We have an application which has a session timeout of 20 minutes. However we have a requirement in which users must be able to access a certain page in the site for 8 hours after the original(20 minute) session was created. The page in question needs to use the session ID of the original session to pull saved session variables from the database which it can use to perform multiple features

Potential Ideas

  1. Storing the session ID in a cookie which has an expiry of 8 hours after the original session was created and using this to pull data from the database - I decided against this as it is not advised to store session ID's in cookies as someone could intercept it.
  2. Store the session ID in cache - same issue as above
  3. Create a new MVC application for the page with an 8 hour session in IIS and when user hits the link to go to the page, it will link to thew new application and it will create a new, separate session which lasts 8 hours - This is the current solution which the legacy Classic ASP application uses. I am hesitant to use this route as I think it is wasteful and time consuming and much more difficult to do in MVC than it is Classic ASP

Does anyone have any ideas to how this requirement can be met, securely?

Improve this question
15
  • its 2018! why do you have a stateful webpage?!?!?
    – Ewan
    May 29, 2018 at 18:21
  • It's just one of the business requirements to allow users to access a page after the "original" session timeout expires. I dislike it but I can't do anything about it
    – Andrew
    May 29, 2018 at 18:24
  • so are you asking "whats the best way to design this feature" or "are there any hacky tricks I can do to avoid refactoring"
    – Ewan
    May 29, 2018 at 18:27
  • Best way to design the feature
    – Andrew
    May 29, 2018 at 18:27
  • get rid of sessions entirely, have a 1 month expiry on a auth2 refresh token, a 20min expiry auth token and store a created date which you check for your 8 hour limit before serving the special page
    – Ewan
    May 29, 2018 at 18:30

2 Answers 2

Reset to default
1

I deal with a similar issue in an app (super long log-in state), and resolved it by storing a GUID in a cookie on the client (via HttpOnly cookie) that is tied to a single login event record on the server.

Technically if someone had physical access to a logged in machine, they could see the cookie and copy the GUID value to be used elsewhere but if they did that, then they already have access to the logged in machine so its pointless to worry about anyway.

Improve this answer
4
  • If the site was hosted on the internet then a malicious user without physical access to the machine could also get the cookie GUID value. I like this idea as the page in question doesn't allow the user to do anything damaging anyway
    – Andrew
    May 29, 2018 at 19:42
  • @Andrew could you elaborate on how the cookie could be compromised? In my app, a compromised login is basically harmless, but I'd like to understand the risks more.
    – GHP
    May 29, 2018 at 21:07
  • If your app doesn't use HTTPS, the cookie will be sent unencrypted and anyone who is watching the web traffic could see the value of the cookie being sent. For more info look up "Session Hijacking"
    – Andrew
    May 29, 2018 at 21:19
  • The site is definitely on HTTPS. "HttpOnly" is a setting a the cookie level that prevents scripts like JavaScript from accessing the cookie, it can only be read by the server-side code.
    – GHP
    May 30, 2018 at 12:57
1

You could just increase the session timeout to 8 hours for all pages. Then you could just do your own "soft-expire" when someone accesses a page after 21 minutes where session should have been expired.

This soft-expire logic could just be placed in global.asax in Application_BeginRequest

Improve this answer
5
  • you sir, are a genius!! ps. remember the session db bit or the server will run out of memory
    – Ewan
    May 29, 2018 at 22:03
  • I dont like the idea of modifying my whole application for this one page though, I prefer the cookie idea
    – Andrew
    May 29, 2018 at 22:48
  • Just pray your app pool doesn't recycle during those 8 hours. Probably not a great design if you ever need to be able to restart your services.
    – John Wu
    May 29, 2018 at 22:55
  • Memory is cheap. The redis session state provider works quite well.
    – Esben Skov Pedersen
    May 30, 2018 at 4:09
  • Yeah, I don't think I will go with this solution
    – Andrew
    May 30, 2018 at 15:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.