i'm using spring+tapestry for authenticate webuser. I wonder is there any technique i can force all users that currently login in to logout let say i'm on scenario where the site is 'under maintenance mode'
p/s: will it able to force all users' running process to finish and only force log out
Two things come to my mind:
use HttpSessionListener to keep track of all sessions and invalidate them when the time comes. To use this you will need a Set of Session objects in your ServletContext (or less preferably - as a static field). Update that Set whenever a session is created or destroyed, and iterate the set when invalidation is needed.
use a Filter (mapped to /*) where, if certain conditions (maintenance == true) are met, invalidate the current session. Thus all users will be logged out on their next action. This would work in cases when "maintenance mode" doesn't mean "stop the whole server", but rather means "no operations should be performed by users, I'm doing something important in the background that should not be interfered"
The problem is trying to let them finish the request and only then log them out. I assume if they hit save on a form, you want the data to be saved but then they should be redirected to the maintenance page. For GET requests, you can just log the user out if the maintenance flag is set. POSTs are a litle harder because you want to complete the request but then sign them out and redirect them to the maintenance page. I would try a request filter. Handle the request like normal, but then invalidate the session and use response.sendRedirect if the maintenance flag is set.
Another option would be to use a JavaScript timer in the layout - hit a page periodically to see if they should be logged out. That probably wouldn't let them finish their current request though.
Related
We are using Angular5 as front-end. Spring Boot JAVA for APIs. We would like to maintain logged in/logged out details of users like, when a user say user1 logged in(field loggedin in table is set as 1), and after logout (loggedin field value updating as 0).
This is working fine in normal scenario. In case, user closes the browser or closes the tab, at that time, API is not triggered so consequently, in table level also it is not updating.
Finally, we thought like, if no APIs are triggered for certain 5 minutes or certain time interval then we have planned to assume the user might logged out. So, we are trying to find out , like if no APIs are calling for last 5 minutes user-wise. How can we arrive it?
Actually, we are new to Spring Boot JAVA. Kindly guide us on this or any other idea or suggestions are greatly appreciated.
Thanks in advance.
I think you are using extra tags to track user activity, maybe you want to limit it to users current actions (like for logout, just update that logged out, as it would implicitly mean used not logged in anymore).
To achieve what you are looking, there is a session associated with every request, maybe new created or the existing one. You can keep a track of sessions created, and if any session is inactive for more than timeout time, you can destroy the session and while doing so, you can update the status of related tags at that step.
Consider the following scenario.
I've a Java EE web application (JSF 2.2, JPA, EJB 3.0 even if the framework doesn't matter here) deployed on Glassfish 3.1.1 with a login protected area, which I'm protecting through the standard Glassfish security mechanisms.
My business model is based on selling access to this web application as a service, forbidding multiple logins at the same time for a single username/password. For this reason I'm keeping a column in my database that I increment upon user login and I decrement upon user logout. Additionally, I've a method in a SessionScoped managed bean annotated with #PreDestroy that takes care of decrementing the counter when the session expires (60 minutes configured in the web.xml via the session-timeout attribute).
When the user try to login with a counter greater than 1, the application notifies him about the issue, inviting him to logut the previous workstation first.
This is working quite well, but we are having an incrementing amount of users that perform their actions, close the browser (without loggin out), and then try to authenticate from a different workstation within the session timeout limit (which, again, we've set to 60 min).
In these cases we would like to be able to offer the opportunity of closing all the previous sessions associated to the user login directly from the new workstation (so an user X, logged with his own session, should be able to ask the termination of different sessions logically linked to its account). I'm aware that if he/she just waits 60 min the session will be eventually terminated by Glassfish but we would like to avoid the support requests coming from this "issue" (you know it's hard to explain this kind of stuff to non-technical users).
My first plan would be to store the jsession ID of the user HTTPSession somewhere, to access the old sessions (if any) via the stored jsession ID and to close or invalidate them on demand. I've read a lot of material on the subject, and I found this SO question with apparently the answer I'm looking for (a method of storing the HTTPSession in a map using the jsessionID as key to get them back). It seems pretty simple and I could implement that in a matter of minutes, BUT the comments below, especially the second part of the answer coming from #BalusC is driving me to ask your opinion on how I should implement this in a safe way.
It's a matter of best practice, how would you guys implement this?
I don't need code, just your opinion as Java EE architects or a reference of some sort of documentation on the topic.
Keep track of all logins in DB (you can use HttpSessionListener to remove entry when session get destroyed). Make sure that you've a boolean column "should kill session now!" in DB which defaults to false. When the action is given to kill all other sessions now, set the boolean to true for those sessions. In a filter, on every request, check the boolean value in DB and handle accordingly.
This way you don't need to have a handle of all physical HttpSession instances.
I am using JBoss server. I have one problem with session. After logged in to the page again I restarted server. But user session is getting logged out. Again It redirects to login page. I need to allow user to see the webpage without logout.
After restarting the server, your login session information is lost. You need to persist it to avoid this.
https://community.jboss.org/wiki/HAWebSessionsViaDatabasePersistence looks like exactly this.
When you restart the application server, all the sessions will be terminated, that is a normal thing, because sessions are kept in the memory to put it simply.
If you want the user to continue on from his previous session, you will have to go through a lot of trouble such as re-creating the session objects and populate them with the data you somehow saved from last session, and a way to authenticate the user without the user entering his password again. That is probably the easy part which you can achieve by storing the session identifier in a cookie and keeping track of it in a database or text file, but re-creating the session itself exactly from where you left off might not be a good or even practical idea.
Two options for storing and restoring the session:
1) Save the data related to the session (items in a shopping cart for instance) in a database or a text file of some sort. (save it on the hard disk) This will prove very difficult, how difficult depending on the complexity of your site.
2) Save the users session data in a cookie along with the session identifier (jsessionid). Again you will need to do some custom work, identifying these cookies and reading them. User can always get rid of cookies, or disable them etc.
If you have a very simple web page that doesn't include any data other than the authentication, you simply want to see the previous page you were at, you can save a cookie in the client identifying the user and the page he was last at.
In my application I have many different JSP forms with multiple stages, that is after each stage the request is send to the Servlet and processed to generate the next form.
The problem is that I need to keep the state of these forms (like in JSF where it is done automatically), so that the user won't have to eneter all the data each time he gets to the error page or navigates back to reenter something he wants to change.
What is the best approach:
1) Store all data in the session, and remove it once the user submitted the final stage of the form.
2) Store it all in the request scope, and read/write each time the user navigates to the different page. However, this does not seem logical since if I save stage 1 and need its data in stage 4, I have to read/write it 3 times instead of just 1 time when using the session scope, and each time the amount of data to be read/written increases.
session scope should be fine
Just keep in mind that session is usually stored in memory so on very busy webservers it can take up a lot of memory.
Both are doable, it depends on your use-case.
If you need a calculation after each step and need to send data to the server anyways, session is better.
If client is Javascript heavy, you can collect all data and only send it after the final step. This would work only if the steps do not depend on data entered.
If you go for the session approach, be careful to make it work when the user opens your app in multiple tabs. This could be done by detecting the session attribute already in the session, or naming the attribute in a way that does not cause conflict.
You should handle steps of the form on client side. and send all of the values together. This will save you a lot of work on session values.
Create a div for each step, wrap them with a form tag, show - hide the divs accordingly. also if you use jquery, selection of dom elements would be much easier.
if you have to make a query on the server side, then the obvious choice is session values, assuming that you don't want to use AJAX, nor JSON.
I wanted to understand how we can implement a safe logout method in a website. I am trying a logout page in jsp. Is destroying a session enough when the user clicks logout ? If it isn't what are the steps necessary for the logout, to be a safe operation for the user ?
Generally I'd say yes, but it depends on what other information you may be storing client-side. For example, if you have any cookies with sensitive information (hopefully you don't) then you should clear those out as well.
If you stored any user related cookies, you need to clean-up them as well. In other words, any information that used by your server to identify a user should be cleaned up. If it's only the session - then in you case that is sufficient.
Define "safe".
You'd also likely want to turn off caching so hitting the "Back" button wouldn't show potentially-sensitive information. Other than that, not sure what else you're concerned about.
Depends on your application requirement what functionality do you want during logout. Apart from refreshing or releasing the user session some times there are few variables set in the session, they should also be released properly.
Yep, once you invalidate session, then the session id is no longer valid, probably the session cookie would be also destroyed, so the session is gone (together with all data stored in session).
In order to logout user (either from servlet or from JSP page):
<%
HttpSession s = request.getSession();
s.invalidate();
%>
That was the easy part. Now, if you store some important, user specyfic data in a custom cookie, then make sure you clean them. The same applies to HTML 5 local storage - it has to be manualy cleaned.