Is there any way to manage the following scenario using Spring:
I have to logout the user if he is inactive for 30 minutes. However, on the elapse of the 28th minute, I have to display a warning pop-up saying that the user will be logged out in 2 more minutes.
If the user responds his session is maintained.
Otherwise, his session expires in 2 minutes and he is redirected to the home page.
Using Spring 3.0.
*Spring is handling all my session management and the servlet container is Tomcat.
The requirements of the client I am working for that any functionality created should function well without javascript as well. This is why I was searching for a Spring based solution.
Sounds like a job for Javascript on the client, rather than something Spring would do.
If you know (or set) the session timeout on the server, you can set a corresponding timer on the client, to go off 2mins prior to the actual session expiry.
If required you can always force the session to end by redirecting the page to the logout URL from Javascript. If your logout destination is set to the home page, then that's where the user would end up.
Related
I am attempting the following flow:
Invalidate the HttpSession
Load balancer redirects the user to a server
User should already be logged in, irregardless of which server they are sent to.
Notes:
Sticky sessions are enabled, but should not matter when the session is invalidated. There are existing rules that log out a user after a certain amount of time, but I need to be able ensure that the user stays logged in when a certain method that invalidates the session is called.
The servers are not clustered and so no server is aware of the other server. It is also impossible to implement Redis or similar in the current environment.
The server is JBoss 7 (EAP 6.1)
I am stuck on the logical flow, and I can't seem to find someone that has done this alread, apart from invalidating with httpSession.invalidate()
but I need to be able ensure that the user stays logged in - then why have those session timeout rules? Which is more important: security or the user experience?
More secure approach and easiest to implement: the front-end uses a timer to alert the user to inactivity a few minutes before the session expires. If the user ignores the alert, too bad. The user must log back in.
Less secure approach and harder to implement, but a better user experience: When the user logs in store a token in shared storage which is associated with the user. Each request includes the token as a header or posted value but never as query parameter so if the session expires the token can be looked up to get the trusted user, and log the user back in without a password. Of course, any session context will still be lost since the session had expired so depending on what the user was doing this could cause confusion for the user.
But how long should the token be considered valid? Suppose the session timeout is 15 minutes (which is a regulatory requirement for some apps), how long should the token be trusted? 30 minutes, 1 hour, 24 hours? It's a slippery slope.
Again, which is more important: security or the user experience?
What are "active sessions" in tomcat? I am trying to monitor active sessions for a Java web application. But the values I am getting are not matching with number of people using web application. Could you please explain?
Basically the number of active sessions is the number of existing or previous browser or other connections with an unique jSESSIONID cookie value. As soon as someone hits your webpage with a browser a new session is initiated and an unique JSESSIONID is assigned to this session. If next hit is performed with the same JSESSIONID (which is transmitted as cookie or url parameter) the session count remains the same. If the parameter is not transmitted a new session is created.
Usually all browsers keep the session id cookie over multiple requests and even multiple tabs or windows (except for incognito tabs/windows of course).
There are multiple reasons why your session count is larger than you user count.
Sessions are held in tomcat for a period of time, with 2 hours being the default. You can change this amount in tomcat settings. So if 100 user logins into your application in first hour, and 100 in second, your total session count will be 200, even if the first 100 users are idle.
Robots like the google bot tend to create tons of sessions. If your page is publicly available check the access logs if there are some bots visiting your page.
If your application is behind the loadbalancer or proxy which are continuously 'pinging' your application for its availability, this pings can create sessions as well.
Finally there are a lot of 'funny' ways your app can get requests from browsers, for example search results prefetching and similar.
Also keep in mind that session is bound to the domain name of the site. So if a user connects to your site via multiple domains (for example www.domain.com for content and static.domain.com for images) each of the connections will have its own session.
Now, there are different way to prevent unneeded session creation, depending on what your exact problem is (and if it is a problem at all).
If you have parts of your application that don't require a session ensure that you don't call request.getSession() somewhere in your code. Also in the jsp you can explicitly turn off session with <%# page session="false" %>
The the session timeout lower to make them expire quicker in tomcat/conf/web.xml <session-config><session-timeout>30</session-timeout></session-config>
The session-timeout value is in minutes.
Finally if you are interested in what is really happening in your application, get yourself an APM (application performance management) tool like MoSKito
I have a Tomcat 7 web server.
After login to it I can see under Cookies that there is jsessionid which, from what I have read is saving the id of the session instance between the user and the web server.
But the thing I cannot understand is that after I login and I stay in the browser.
I can stop the server, even un install it from the system and re-install it.
and then after I restart it I can continue navigating in the website without needing to enter credentials or anything like that, as if nothing happened in the background - I just can move on with the same jesssionId.
So basically I will divide my question into sub-question so it will be easier to answer:
1. How is it even possible that after stopping the service or even un install it it can still happen?
2. How excatly is the jesessionID created? I mean is it possible that it is the same jsession id?
3.When exactly does the jsessionID is being created?
4. Is it possible to change this behavior and "invalidate" the session so the user will have to re-enter his credentials?
5. Following question #4, what is common in most of the services? demand to login again or to enable the use of the old session id ?
Thanks a lot!
In answer to your questions:
Tomcat's session Manager will serialize session data and save it to a file to persist it across restarts. You can disable this.
Tomcat's SessionId Generator determines the exact way the id is created.
Here a good answer for when session ids are created: Under what conditions is a JSESSIONID created?
If your goal is to invalidate sessions after a Tomcat restart, you can do this by disabling session persistence.
Typically a user would want to be considered "logged in" until they click a "log out" link or button in your application. You can also adjust the session expiration time if you want the session to expire after a period of inactivity. How exactly this should work is up to you and depends on your application's use cases.
I'm developing a vaadin 7 application with user authentication and authorization using jaas with a realm defined in the application server (glassfish).
I have this requirements:
A user can stay logged in for some time, so that he doesn't need to enter his password every time.I do this by setting the session timeout of the http session.
The vaadin session can lock some resources and while locked, no other session can use this resource. All locked resources are released when the vaadin session is closed.
I set the heartbeat intervall to only 15 seconds.
I'm not able to get both requirements to work at the same time.
If I set the http session timeout to a minute, the resources are released a minute after closing the browser, but the user is not authenticated the next time.
If I set the the https session timeout to some days, the user is authenticated for this time but the vaadin session is not instantly closed after 3 missed heartbeats. It will only be closed when the user uses the application the next time with the same http session.
How is it possible to achieve both requirements?
Here more information the the technology I'm using:
Glassfish 4
web-app 3.1
vaadin 7.1.7
vaadin-cdi 1.0-SNAPSHOT
Thanks for any Help
You might want to have a look st Spring Security and especially Remember-Me Authentication - an alternative I personally would use instead of trying to implement a secure persistent login myself.
If you want to go the DIY path:
I think that trying to separate the Vaadin from the Http Session is not such a good idea. The Application lifecycle section of the Vaadin book says:
When a new client connects, it creates a new user session, represented by an instance of VaadinSession. Sessions are tracked using cookies stored in the browser. … [The Vaadin Session] also provides access to the lower-level session objects, HttpSession and PortletSession, through a WrappedSession.
Perhaps you could change your solution of the first requirement ("A user can stay logged in for some time, so that he doesn't need to enter his password every time.") to by separating the login credentials from the http session?
You could store some timed-stamped and unique-id as a cookie (with expire-date) and customize the VaadinServlet with your own SessionInitListener and SessionDestroyListener to check for it (and set it) and either require the login credentials or accept the credentials from the client depending on the checks you do on the server.
There is some ambiguity in your question, but I believe you can resolve it by using your own close() method. You could create your own Vaadin Application class, with a custom close() method, or use TPTApplication and override its close() method:
http://vaadin.com/directory#addon/toolkit-productivity-tools:vaadin
Make sure the close is called when the session is closed, and do your cleanup there. This will also be called when the session ends.
If you can't ensure this (ie. if the user just closes the window and you don't have some javascript to deal with this), you can intercept the window close with Vaadin, but its quite a bit more work. When the user tries to close the window, you interrupt the process, do what you need to do via a callback, and then let the close occur. The details on how to do the interrupting from vaadin are shown here:
https://vaadin.com/forum/#!/thread/44621/44668
https://vaadin.com/forum/#!/thread/83207/83206
The callback is client side only, so you will have to make a call to the server (Get/POST via javascript) that will pass along the session id to a servlet that you have listening for this. The servlet would then release the locks using the passed in session id.
The key is listening for the window to close and being able to respond to it appropriately.
I have a web application in Tomcat 7 which keeps user information in session as a DTO object. I also have Spring security enabled for my project which automatically redirects a user to a login page if the user does not have a session.
If I log in to my application once and then I restart Tomcat in Eclipse what happens is that my session gets flushed out but the cookie does not go.
What this means is that after server restart there is no UserDto in session but a valid JSESSIONID remains with browser. Thus spring security still thinks that the user is logged in when in fact he's not.
Why is this happening? (I have check the type of JSESSIONID cookie by viewing page info in Firefox it says - Expire: At end of session. Thus it should ideally expire at server restart or shouldn't it?)
Edit: Though Firefox says Expire: At end of session the cookie is still there if I close and restart Firefox.
From Servlet 3.0 to add expire date to a cookie you can add cookie-config to your web.xml file
<session-config>
<session-timeout>30</session-timeout>
<cookie-config>
<max-age>1800</max-age>
</cookie-config>
</session-config>
The cookie is held in the browser - when the server restarts, but the browser continues to run, it will hold onto the cookie and present this to the server on next request.
Now on the server side, you have multiple options: You can configure tomcat's SessionManager to persist on disk and read the content upon restart - this is an option that also is used to distribute sessions between multiple tomcats in a cluster: When the session is serialized to disk, any server can continue the session by "just" deserializing it. There's some cost implied (as you constantly need to serialize sessions)
Currently I can't give you more concrete hints than this - but if you look it up and understand the difference between where the cookie is stored, why it doesn't change on server restart and that you'll have to look up tomcat documentation of the session manager, you'll hopefully manage to figure it out.
Tomcat will generate a JSESSIONID automatically if you have used session in you web project.
If the session id changed then the JSESSIONID will changed corresponds. Because
the JSESSIONID indicates the seesion ID of the WEB project.
It will expire when the server stop(in default it will expire within 30 minutes), but the cookie cannot delete automatically.
JSESSIONID can configs in server.xml file of tomcat.
While you log in succesfully, SpringSecurity stores a cookie in your browser.
When the browser sends a request, SpringSecurity checks what's in the cookie. If SpringSecurity finds the value it stored before, it thinks you have logged in, so SpringSecurity won't redirect to the login page.