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.
Related
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
I can redirect a user to home page upon session logout.. this was very simple. However, if an user had logged into the app and had the page open, even on session time out, he is able to perform all the functions(this is bad).
The redirect does not happen until the page is refreshed, or submitted to the server... there are some update functions that could be done by the user even if he is not currently logged in... I have done a lot of research but unable to fix this solution. I also found this thread but it seems to have no proper answer:
Spring Security 3.1 - Automatically redirect to login page when session-timeout occurs
For example, most of the banking sites log you out after a time out.. they do not wait until you come back and then submit a request before you are redirected to home page.
HTTP is stateless. To achieve some form of state the server can maintain a session for each user by giving them a session id on their first request. The user would have to resend that session id on each future request to identify that the other requests happen within the same session.
Because the session is maintained by the server, there is no way to notify the client that the session has timed out.
Instead, if the user makes a new request when the session is timed out, their session ID is no longer good and therefore you can take a particular action like redirect them to login page.
Assuming nothing works out. You may want to consider below mentioned approches:
Approach 1:
Create a cookie on browser and have encrypted timestamp in it that will contain last visited/request timestamp from browser, for each request first get get this cookie value and compare with the pre-defined session out time, if session-out time reached then redirect user to error page else serve the request. On logout delete the cookie.
Why encrypted value for timestamp: if somehow user gets to know about cookie used for session timeout then (s)he can change this value in browser and keep on sending this request.
Approach 2:
You can also achieve this by making an entry in your database for every logged-in user and updating timestamp in this database for each request. For each incoming request get this timestamp from database and compare it with pre-defined value for timeout and handle accordingly. On logout delete the entry.
In both the approaches explicitly perform response.redirect("errorPageUrl");
I am new to lift and trying to write a simple login application. When I leave my login page for some time, and I enter username and password it doesn't login instead it perform session expire behavior.
I checked the log and found that whenever I got INFO - Session navoo0xdu1ia1vi8m1c0cnl3w expired log message, the above behavior happens.
I am not able to understand why request is using the existing session, even if it's already expired. Please guide me where can I found documentation/example/tutorial to understand this behavior and how to implement simple session based login functionality.
Any help will be appreciated since this problem is bottleneck to me. I googled a lot but couldn't find anything useful.
If your session is expiring then it is because of one of two things:
1) The value set in LiftRules.sessionInactivityTimeout
or
2) The value set for session expiry within your container session.
The former is actually set to nothing by default, which means the latter will override it. Be aware however that provided you are interacting with Lift and have not disabled the heartbeat pulse then sessions do not expire. If you watch the AJAX traffic you will notice a page heartbeat used for function GC which keeps the page bound functions alive.
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).