Everything I read about cookies says that setting the expiry time of a cookie to zero should make it a `session' cookie, which the browser will then delete upon exit.
http://www.cookiecentral.com/faq/ says that :
"...generally a session is the length of time that the browser is open for..."
http://php.net/manual/en/function.setcookie.php says :
"If set to 0, or omitted, the cookie will expire at the end of the session (when the browser closes)."
However, some experimenting in Firefox (3.0.8) shows that:
cookies set as session and secure get deleted on exit
cookies set as session only do not get deleted on exit
Opera (9.64) behaves as I would expect, deleting the session cookies upon exit whether set as secure or not.
I wanted to be able to rely on this in a web-app I'm working on (having a secure cookie and an insecure cookie as a "logged-in" flag and having them expire together, either with a real time or 0 for a session), but it seems that even if it's in the standard then browsers are not consistent enough to rely on it :/
Is this a bug in the browser, expected behaviour, and/or is the actual lifetime of session cookies not really defined in the standard?
You should never rely on client-side features.
The feature you're working on is usually implemented storing the session ID client-side and the real user info server-side (its ID, whether he's logged in or not, his personal info, etc).
Also bear in mind cookies get sent in every request, so the less you store in a cookie, the better.
Related
I have a very straightforward session system on my website: User logs in and the response on success contains a session token. The session token is then stored as a cookie with no expiry (expires=Fri, 31 Dec 9999 23:59:59 GMT) and root path (path=/).
On requests which require authentication, the client will send the session token value as part of the message, and as a fallback, also as a header and cookie.
Even so, from time to time I get users that just lose their sessions. Their session tokens are still valid, and they haven't logged out. All of a sudden, they apparently don't have the session cookie anymore. They were able to make requests for a while, and for many thousands of requests a day this happens maybe once every day or two so it's a rare occurrence. The requests don't seem to be malicious, they're just normal users who have the website open for a while and suddenly lose auth.
What are some things that can cause this (I expect in at least some cases it's some odd browser/OS setting out of my control)? What are some ways I can prevent this from happening without necessarily knowing the cause?
google Chrome, Firefox and other browsers plan to abandon cookies in near future source1, here is what you need to know. about GDPR and why so.
EU’s General Data Protection Regulation (GDPR) to let users from inside Europe control the activation of cookies and trackers that collect their personal data.
this could be a pain for companies eating cookies. because of the strict legal atmosphere for cookies these days.
a more robust Method to store persistent client side data is discussed here, you can even store whole databases via these methods discussed in MDN webpage. MDN=Mozilla developer Network.
Client-side storage: Link
Web Storage API : LINK
IndexedDB : Link
LocalStorage : LINK (next best alternative for cookies)
Highlights of LocalStorage API:
localStorage does the same thing, but persists even when the browser is closed and reopened. ie system reboot does not affect it.
Stores data with no expiration date, and
gets cleared only through JavaScript, or clearing the Browser cache / Locally Stored Data.
Storage limit is the non limiting around 5MB!
Are you perhaps redirecting domains? So for example: you SET the cookie ok productlogin.com and you redirect to product.com or any other server where you then want to READ the cookie? Because that won't work.
It could also be that your app is requesting the wrong cookie. Are you matching the same session? It could help us if you have some code to share.
Lets say session for an application is opened and its session expiry time is 15 min.
Scenarios:
Leaving the application for 15 min and doing some action after that - leading to Login Page.
In other way I am removing the Browser cookies by using (Ctrl+Shift+Del) and trying to navigate in the application - leading to Login Page.
The Question is: Will both of the above cases were one and the same or will there be any difference in the behavior.
The first scenario is based on a cookie expiring while the second one will have the cookie removed.
If you are guaranteed the refresh for the first case is made after the cookie expired, then the client behaviour will be the same (login page) although the internal workings will be different (check the cookie exists vs check its expiry date)
If you can't guarantee the operation will happen after the cookie expiry, then you won't get the same outcome.
Depending on what you do on the server, you might end up with multiple sessions for the same user in the second case, because the server doesn't know the user has deleted the cookie (there are mechanisms to compensate for this though).
According to Where are $_SESSION variables stored?: "Usually the session-id is stored in a cookie, but it can also be appended to urls". Once I read that, I asked myseld: so, why is it said that the session-id is deleted when closing the browsers window if it is stored in a cookie?
Then, after Googling a little bit more about it, I found that there are two different types of cookies: session cookies and persistent cookies.
I guess that the session-id is stored in a session cookie, but: beyond the name evidence, why is a session stored in a session cookie and not in a persistent cookie? What is the need of creating a new session-id every time the browser is opened? Why don't re-use it?
There are many reasons you store sessions in session cookies. One case is public computers: if the previous user has logged into their bank account at the library to pay bills you don't want the next user to be able to log into that session by just looking at the History log in the browser. Being sure that the session is gone by closing the browser alleviates this.
You can also use persistent cookies, and many do too, such as Gmail, but what is then important is to set an expiration time that is not too long. Otherwise, if someone gets hold of the session id they can use that forever. Usually the server will send you a new valid session id some minutes before the next goes out to keep your session alive.
What's an elegant way in Classic ASP to check if session cookies are enabled in a user's browser using server side code (because javascript might be disabled as well).
I have a solution of my own but it looks ugly as hell.
#James - that doesn't differentiate between setting a session cookie and a general purpose cookie though (IE lets you differentiate between First Party, Session Cookies and Third Party, but I see with Firefox they only differentiate between First Party and Third Party)? I'm setting a session value in a login page then doing a Response.Redirect kinda thing and checking to see if the session value is still valid.
Unless you specify an expiry on the cookie it will be a session cookie. The term session is a bit overloaded in HTTP. When the IE dialog refers to a session cookie it means any cookie that is only stored in process memory and not persisted to disk, therefore only lives for the duration of the process (the session). Start another IExplore.exe process and you have another session which will not have the values of any previous or extant session cookies.
You are correct though that you can test whether even session level cookies are being blocked by just storing a value in the session object and testing for its presence on a redirect.
Well, the "ugly as hell" method we used, was to set a cookie and redirect to a new page. In the code for the new page, see if the cookie was set. Since the only way to get to the second page is to be redirected there when the cookie is set, it's presence or absence should tell the state of the browser.
Generally speaking, when given a cookie that has no expiration period, modern browsers will consider this cookie to be a 'session cookie', they will remove the cookie at the end of the browsing session (generally when the browser instance closes).
IE, Opera, Safari and Chrome all support this behavior.
However firefox (3.0.9 latest proper release) appears not to follow this rule, from what I can tell it doesn't expire the cookies when the browser is closed, or when the user logs off or restarts the OS..
So, why does firefox refer to these as session cookies, when they last aparently indefinitely?
Does anyone know how Firefox handles session cookie expiration?
This is apparently by design. Check out this Bugzilla bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=443354
Firefox has a feature where you close Firefox and it offers to save all your tabs, and then you restore the browser and those tabs come back. That's called session restore. What I didn't realize is that it'll also restore all the session cookies for those pages too! It treats it like you had never closed the browser.
This makes sense in the sense that if your browser crashed you get right back to where you were, but is a little disconcerting for web devs used to session cookies getting cleared. I've got some old session cookies from months ago that were set by sites I always have open in tabs.
To test this out, close all the tabs in your browser, then close the browser and restart it. I think the session cookies for your site should clear in that case. Otherwise you'd have to turn off session restore.
Two ideas :
You have a problem with your session manager (the one included in FF3 or one included in an extension, like tabmixplus)
Use Firebug + FireCookie (https://addons.mozilla.org/en-US/firefox/addon/6683) to debug !
This should work. I used to be one of the cookie module testers, and I don't think there is any design reason this would behave differently (although if you crash, the session cookies might be designed to live on when you restart...)
Are you viewing the cookies in the "Preferences" menu > "Privacy" Tab > "Show Cookies..." button?
Also, have you tried a new profile?
I disagree with meandmycode above.
The HTTP spec https://www.ietf.org/rfc/rfc6265.txt talks about what a client should do with Set-Cookie headers with Expires:
If the server wishes the user agent to persist the cookie over multiple "sessions" (e.g., user agent restarts), the server can specify an expiration date in the Expires attribute. Note that the user agent might delete the cookie before the expiration date if the user agent's cookie store exceeds its quota or if the user manually deletes the server's cookie.
The logical extension of this is that the ONLY way the server has to require that the browser does not maintain a Cookie on exit is to set no Expires value (i.e a session cookie). If a browser does not honor that semantic then its not honoring the server's response.
Essentially the user agent is deciding to ignore the server request and act as if an Expires value had been set.
This is a bit of a concern in shared user environments. If I set a authentication cookie that is set to expire at the end of the session. This will persist in Firefox after the browser has been closed and another user starts up Firefox. Cookies are set with an expiry date for a reason!
I'm flummoxed that Mozilla have left this as it is for several years.
OK.. so I quit FF and switch off the PC.
Next day FF starts and opens the last set of pages (nice handy feature) BUT it restores the sessions and I'm logged back in to sites which have no "save my settings" feature.
I know because they are sites I built.
Whatever I do with php ini settings the sessions are restored.
They absolutely should not be restored.
Pages yes, but sessions with cookie ini set to '0' no.
I don't understand why this is not flagged as a security hole.
Sure I can do some additional checking on the server side, to see if a login should be allowed, based on time from last log in, but it shouldn't be needed.
A session should NOT persist.
FF is manipulating cookie expiry settings.
In my case, it was because of pinned tabs that automatically restored the session even if this option was disabled in Firefox settings. So if you unpin the tabs, the session won't be restored.
Well it is disconcerting to me. My system is set up so that users can hit EXIT whereby I destroy all session cookies. But if a user closes the browser without actually choosing to Exit, I'd like the session cookies cleared.
I actually tested it with Google Chrome, IE 9, and works fine. But Firefox is reluctant to kill this "session" (as reported by Firebug) cookies.
OK. This is what I did. I chose Exit from FireFox main menu and from then on, did it fine as expected (Dont know why).