Does the session become nil? Does the change take effect only on the next request?
I think I just asked three questions now...
You can try to explore by using the similar settings:
AppName::Application.config.session_store :cookie_store, key: '_session_key', expire_after: 20.seconds
Then open up dev tools in your browser and go to cookies and select localhost cookies to see what happens.
I found out that:
Session cookie gets deleted after the expiration time
Expiration time for a cookie gets updated automatically (re-set) upon any request (even background ajax request counts)
The effect by default will take place upon the next request (refreshing the page for example) and if you use typical authentication (has_secure_password_ for example) user should be logged out
I found the last comment on the ActionController::Base documentation page really helpful on this topic
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).
In my application I am saving the logout time of the user. This is working fine when the user clicks the login button, but my requirement is to store the logout time even if the user closes the browser. If this is not possible please tell me the way how to destroy the session as soon as user closes the window.
Any help would be appreciated.
It used to be you had to do synchronous Ajax in the event handler. Don't know if that's still true in modern browsers. If you go asynchronous, be sure to test with realistic client load so that you don't run into a race condition that only shows up among your users.
I would suggest some kind of heart beat Ajax call from the client, say every five minutes. If you miss two such calls in a row you kill the session server-side. That will take care of all situations where the user doesn't log out (browser crash, OS crash, network failure etc).
Potential problems with acting on unload events:
What happens if the user has your app/site open i several tabs and closes one of them? You need to inform the user that there will be a cross-tab logout.
Browsers have a history of restrictions on what you can do on unload to prevent ever-popups and infinite loops that prevent the user from closing the browser. You never know what will come in the future. History here: http://www.hunlock.com/blogs/Mastering_The_Back_Button_With_Javascript and via the StackOverflow link in the reply above.
As per this answer, you should be able to handle the beforeunload event and then do an AJAX logout.
Untested, but it should work like this:
Ext.EventManager.on(window, 'beforeunload', function() {
Ext.Ajax.request({
url: 'logout.json',
timeout: 60000
});
});
This answers the last part of the question. Auto close the session with closing the browser. According to Wikipedia: When an expiry date or validity interval is not set at cookie creation time, a session cookie is created. Web browsers normally delete session cookies when the user closes the browser.
The task at hand is to create a cookie without an expiry date using Ext-state-CookieProvider. Leaving out the expires configuration at all, will cause ExtJS to default it to 7 days. Check the source for this. Therefore you need to create the cookie with an explicit expires of null, like so:
var cp = Ext.create('Ext.state.CookieProvider', {
expires: null
});
All cookie values will be deleted when the browser closes.
How do websites generally log users out and send them to the log in screen automatically when a user's session expires? Is this done through ajax or running async handlers? Can you give me a bit of an explanation.
Banks and such use a client-side timeout via javascript, or something similar. Really, though, the server handles the actual session, so if you disabled the client-side logic it would act as if you were attempting to make transactions while logged out.
Use a cookie as well as a session.
Cookie must be set when a session is
started.
If the cookie is present but the
session is gone, redirect to the
login screen.
If there is no session and no cookie
do nothing
(pardon me if you can't do that because I never used ASP and basing my answer on my PHP knowledge)
Typically, you set an expiration timestamp on your session ID cookie. When the cookie fails to be sent, the client is logged off (no given session ID).
This method is often combined with JavaScript and another timestamp token. When the timers start running down, a notification is sent that allows the user to "refresh" their session... essentially, making a request before the session timestamp expires.
The "refresh" request could be anything, even something as simple as an image load.
If you are using Tomcat you can use its built in <security-constraint> mechanism within your web.xml definition. All of the timing, login screen, and page redirects are handled by Tomcat with little effort on your part other than definitions.
Oh, IIS... nevermind.
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).