CODEWITHSUNDEEP
javascript
pertrai1
pertrai1

Reputation: 4318

Session timeout issues

If there is a timeout set on one of our pages, and that same page is opened in another window/tab, is there a way to destroy/stop the timeout in the other window? We have employees who will use our system but open it again from their favorites. If they do this the already opened window will run the interval and then timeout. So while they are working in the new window they opened they will not be able to finish what they are doing because the other window timed them out.

Are there solutions to do this if a new window is opened?

Upvotes: 0

Views: 2187

Answers (1)

josh3736
josh3736

Reputation: 144832

In any sane web application, it is safe to have multiple windows open – especially in respect to session timeouts, because "session" state is managed by the server, not the client.

First, consider why web servers manage session state. HTTP was designed as a stateless protocol, which means any given request cannot conclusively identify who issued the request. This is fine for serving static resources, but is obviously not useful if we want to develop a more interactive app; Netscape later added cookies to their browser to address this.

Cookies solve the state problem (since the browser will issue consequent requests with the cookie[s]), but they are inherently insecure: a malicious client could modify a site's cookies. If, for example, upon login we set a cookie called uid to the user's ID, it would be trivial for someone to fake a cookie with uid=1, which might be your site's administrator account. Oops.

This is why web application frameworks invented the "session" construct. Each time a request is made with no cookie, the server creates a new (random) session key and sets the client's session cookie to that key. The web server keeps track of sessions and all state associated with each session. Important here is that the key itself contains no data, is large and random enough (has relatively high entropy), and is useless outside of your server. It is thus not possible to know how to change the key to gain access to other sessions.

Think of sessions as a large array – one item for each session, and a map of variables in that item. Conceptually, it might look something like this: (remember that this data resides on the server!)

session['safa4fwsa34rff4j9'] = { uid: 1, ... }
session['ajiokinmoi3235000'] = { uid: 4312, ... }
session['9lij34fff032e40k0'] = { uid: 9098, ... }

If I was signed in as user 1, my browser would send a cookie with sid=safa4fwsa34rff4j9. The server looks up this session, and passes the saved state ({uid:1}) on to your scripts. When your scripts are done, the server saves any changes back into its data store. (Session data is often kept in-memory, but in large sites, session data can be saved in a database.)

So what does all of this have to do with timeouts? This session data cannot be kept indefinitely because you'd eventually run out of storage space (whether that means running out of RAM or filling up the database your sessions are stored in).

Instead, the server also stores an expiration date & time with each session. Each time the session is accessed (by a client sending a request with the session's key), the expiration date is reset. The expiration date can be set anywhere from a seconds from now to years from now (depending on what server you're using). You configure how long you want your server to hang on to sessions; IIS defaults to 10 minutes, PHP to ~24 minutes.

In this model, the only thing that really matters is the last time a client issued any request, thus resetting his session's expiration/timeout. It wouldn't matter if multiple windows are open, because as long as one of them have accessed a page recently, all windows will still be active. If the session expires, then all windows are automatically expired when they make their next request.

Something that might muddy this issue is if you're doing some kind of AJAX polling, but the question doesn't indicate what technologies are being used. (@OP, it would be helpful if you included tags for your server stack.)

To summarize all of this: If you're doing any kind session management/expiration on the client, you're doing it wrong. Your app is likely insecure.

Upvotes: 3

Related Questions