4

I thought that sessions were stored on the client side because of the session getting deleted when the browser closes. However, today I've been told that this is not true and that the session is stored on the server.

So how does a session know when a browser was closed, so that the session gets deleted?

hakre
  • 193,403
  • 52
  • 435
  • 836
homerun
  • 19,837
  • 15
  • 45
  • 70

3 Answers3

6

It doesn't. There are two factors at play:

  • the lifetime of the cookie on the client-side; This cookie contains the session ID. It does not have anything to do with the session data itself.

    The manual probably doesn't stress this enough:

    This has nothing to do with lifetime of a session

    Whatever you set this setting to, it won't change how long sessions live on your server.

    This only changes HTTP cache expiration time (Expires: and Cache-Control: max-age headers), which advise browser for how long it can keep pages cached in user's cache without having to reload them from the server.

  • the lifetime of the session data on the server-side; The session is "activated" via a lookup with the session ID from the client. Its lifetime is controlled via session garbage collection settings discussed here.

    A commenter posted on the session.cache_expire documentation page, presumably actually talking about the session data:

    What most people also don't know, is that most Linux distributions (Debian and Ubuntu for me atleast) have a cronbjob that cleans up your session dir using the value set in the global /etc/php5/php.ini (which defaults to 24mins). So even if you set a value larger in your scripts, the cronbjob will still cleanup sessions using the global value.

    If you run into that situation, you can set the global value higher in /etc/php5/php.ini, disable the cronjob or even better, do your own session cleanup in a non-systemwide directory or a database.

    As you can see, confusing abounds amongst the community when making the distinction between session tracking and session data storage.

Community
  • 1
  • 1
Lightness Races in Orbit
  • 378,754
  • 76
  • 643
  • 1,055
3

Session is identified by a cookie, which does get stored in the browser. It can have an expiry date/time, or it can be set to expire when the browser is closed. When the cookie expires, you can't identify your session storage any more, and the session is effectively expired. It does not get deleted unless the system admins or programmers specifically make a cleanup.

EDIT Just noticed the PHP tag. For how PHP cleans up its session files, check this question.

Community
  • 1
  • 1
Amadan
  • 191,408
  • 23
  • 240
  • 301
  • Just for clarification: When a PHP session is "set to expire when the browser is closed" means that the expiration time gets automatically postponed for a given number of minutes every time the session is accessed (by the client browser using the session ID). If the browser gets closed the session will not get accessed in that time frame, and the session will expire, but not before the minutes set at the last access have passed, and certainly not right away after browser closure. – Sebastián Grignoli Jan 02 '12 at 15:09
  • The session can also reach the timeout without the browser getting closed if the user does not interact with the server for several minutes. Notice that interacting with the server is not the same as interacting with the page: Early users of Hotmail used to fail to send long mails that took more than 15 minutes to write because the server (haven´t heard of them for 15 minutes) did not postpone the expiraton of the session. When they hit "Send" they found out that they had been logged out already and the mail data was usually lost. – Sebastián Grignoli Jan 02 '12 at 15:14
  • @SebastiánGrignoli: I was talking about the cookie. When the cookie has no `Expires` or `Max-Age` attributes, it will be deleted by the browser when the browser is closed. If you try to access the page even the next second, you will not be able to access your session, unless you hack it by reintroducing the session cookie manually. In contrast (again strictly speaking), there is no setting to expire the session (in PHP sense) on browser close, since server can't know when the browser is closed. – Amadan Jan 02 '12 at 15:33
  • @Amadan: I was not trying to correct you, just to clarify things for the OP that asked how the server knows that the browser was closed. – Sebastián Grignoli Jan 02 '12 at 15:40
  • @SebastiánGrignoli: Lol... so much confusion from a simple question... Thanks for the additional info, then. – Amadan Jan 02 '12 at 16:04
1

The server has no way of knowing when the browser is closed. Closing the browser will delete the session ID cookie from the client.

The session is deleted from the server once there are no requests in a given amount of time (the session timeout).

SLaks
  • 868,454
  • 176
  • 1,908
  • 1,964
  • 2
    I didn't downvote but I'd be wary of making assertions like that, @SebastiánGrignoli, without citing some documentation, especially when other answers conflict. – Lightness Races in Orbit Jan 01 '12 at 15:51
  • 2
    Incorrect. The session can *expire* either on browser close or on timeout, depending on how it is programmed; and it does not have any correlation with *deletion*. – Amadan Jan 01 '12 at 15:53
  • @Amadan, FWIW, I *sincerely* doubt the OP is making this explicit distinction between expiration and data deletion, given the apparent level of before-hand knowledge of the subject. – bzlm Jan 01 '12 at 15:55
  • 2
    @Amadan: That's not possible; the server cannot know when the browser is closed. You can resurrect a session after closing the browser using Fiddler. – SLaks Jan 01 '12 at 15:55
  • I agree, but downvoting is not the way to go. You could ask for clarification using the comments. SLaks is talking about the session on the server side. The browser forgets the cookie that identifies the session, so it will never be accessed again, so the timeout will eventually get reached and the server will consider it expired (not really deleting it), but this does not happen right away when the browser closes. – Sebastián Grignoli Jan 01 '12 at 15:56
  • @SLaks: Expiry and deletion are orthogonal. Deletion can occur retroactively when prior expiry is detected in future HTTP requests (well, sort of). – Lightness Races in Orbit Jan 01 '12 at 15:56
  • @SebastiánGrignoli: Downvoting incorrect answers is absolutely the way to go. _[disclaimer: I still am not claiming that this answer is correct or not; I will note though that this answer changed significantly within the edit grace period]_ – Lightness Races in Orbit Jan 01 '12 at 15:57
  • @TomalakGeret'kal, I agree, but this answer is not incorrect. Also, this should be debated on MetaStackOverflow, not here. – Sebastián Grignoli Jan 01 '12 at 15:59
  • @bzlm: That doesn't mean that an answer also failing to make that distinction is magically rendered correct. – Lightness Races in Orbit Jan 01 '12 at 15:59
  • 1
    I would delete this answer, but I don't want to kill the discussion. – SLaks Jan 01 '12 at 16:00
  • @SebastiánGrignoli: What? No, it should not. Whether this answer is correct or not has absolutely nothing to do with `meta`, and I will refer you back to my initial comment: "this answer is not incorrect" is very generous of you, but you've not provided any reason to actually believe that over Amadan. – Lightness Races in Orbit Jan 01 '12 at 16:00
  • @TomalakGeret'kal, hence the FWIW at the start. :) Are you all hungover from newyear's, or why are you bickering over something as trivial as this? – bzlm Jan 01 '12 at 16:01
  • 1
    @bzim: If people are ignorant about proper distinctions, let's *educate* them, not perpetuate their incorrect terminology. – Amadan Jan 01 '12 at 16:01
  • @bzlm: I'm not bickering at all. If you write a comment that I disagree with, I will reply with why I disagree with it. There's no malice or hungoverness involved... it's called _scientific discussion_, and it's key to continued evolution of human understanding of all sorts of things. Let's not stifle it, eh? – Lightness Races in Orbit Jan 01 '12 at 16:02
  • Actually, I retract my downvote. The answer *is* correct, literally, now that I reread it - but it *is* confusing, because it does not address the OP's concern (why does the *client* lose the session data, whereas @SLaks talks about the *server* without making the distinction explicit). (Or at least I *will* retract once SO lets me.) – Amadan Jan 01 '12 at 16:04
  • @TomalakGeret'kal I didn't mean that the correctness of an answer should be debated on meta. I meant that we shoud debate whether or not users should downvote incomplete but correct answers. – Sebastián Grignoli Jan 01 '12 at 16:07
  • @SLaks: A bit :P Specifically, PHP sessions autodelete after session timeout - not all session implementations have this; and closing the browser might or might not delete the cookie (depending on the cookie expiry attributes). But yeah, much clearer than before. – Amadan Jan 01 '12 at 16:08
  • @TomalakGeret'kal And I didn't find necessary to provide any reason to why the answer is correct since bzlm and SLaks already did that. – Sebastián Grignoli Jan 01 '12 at 16:13
  • @Amadan: For the sake of educating people correcting every small detail, you where wrong when you sad that the session can expire either on browser close or on timeout. Closing the browser does not expire the session. It can be deleted by the program at any moment, yes, but usually it's not possible for the server to know whether the browser was closed or not. – Sebastián Grignoli Jan 01 '12 at 16:19
  • @SebastiánGrignoli: Yes. I guess I deserve that. PHP aside, which uses the term more specifically, "session expiration" can be used synonymously with "session cookie expiration". This is why I make a much stronger distinction between expriation and deletion. – Amadan Jan 01 '12 at 16:54
  • @SebastiánGrignoli: Nobody's talking about incomplete answers; the people who downvoted believed the answer to be incorrect. And, yes, a session can expire by browser closure; but that is an "indirect action" and will not/cannot lead to immediate physical erasure of the session state; regardless, it's "expired" because the browser will no longer attempt to use that session. We're going in circles. – Lightness Races in Orbit Jan 01 '12 at 17:08
  • @TomalakGeret'kal: A session cannot expire by browser closure. Expiration means that the expiration time has been reached. As SLaks said, closing the browser only deletes the cookie, and usually makes impossible to the user to access the data again, but the data is still there and someone with Fiddler could resurrect it. Deletion is something completely different that can be done by the program at any moment, or by a cleanup process only after expiration time of the session, not before that, even after closing the browser. – Sebastián Grignoli Jan 01 '12 at 17:25
  • @SebastiánGrignoli: I submit that "expiration" occurs _either_ when the expiration time has been reached, or when the browser has decided that it definitely won't be using that session again (by clearing the cookie) -- there's no difference in my view. In _BOTH_ cases it's a cookie being deleted; it's the client that's in control, and none of it has anything to do with the cleanup of session data. – Lightness Races in Orbit Jan 01 '12 at 18:31
  • FYI I personally believe that this answer as it stands at present is correct; I also believe that its original version was incorrect. However this is the first time I've made a claim about the answer either way. – Lightness Races in Orbit Jan 01 '12 at 18:32
  • @TomalakGeret'kal I know you submitted that, and it's wrong. The session does not expire at browser closure, as it can be accessed with Fiddler as SLaks said in his original (correct) answer. The session data is still available to the server, and will be until the expiration time. The definition of expiration is "being rendered invalid by timeout". Any other way of deleting the data is, well, deleting it on purpose before expiration. – Sebastián Grignoli Jan 02 '12 at 14:57
  • Anayway, I can't vote it up again, so I guess that -1 will be the score for now. I think that an incomplete answer should get less upvotes than the others, and probably a score of 0, but no downvotes as it's not wrong. – Sebastián Grignoli Jan 02 '12 at 15:02
  • @SebastiánGrignoli: Perhaps I'm having trouble expressing myself, or perhaps you're having trouble understanding me, but we're going around in circles because I am proposing a more open-minded view of the English term "expired" that I'm not sure you've quite grokked. `The definition of expiration is "being rendered invalid by timeout"` is not something I've ever seen in an English dictionary. Either way, it doesn't really matter any more. – Lightness Races in Orbit Jan 02 '12 at 15:14
  • Perhaps I should broaden my definition of expiring... when my wife asks me what happen to the pie we had in the fridge I will say that it "expired". ;) I agree It doesn't really matter anymore. I was just trying to state that the answer didn't deserve a downvote and someone asked me to give reasons for why I thought it was correct. Have a nice day. – Sebastián Grignoli Jan 02 '12 at 15:25