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.
Related
I'm using OpenID. How do I make it so that the user stays logged in for a long time even after closing the browser window?
How do I store and get access to the user's User object?
Basically, I guess I just don't really understand how sessions work in Java.
So you actually want like a "Remember me on this computer" option? This is actually unrelated to OpenID part. Here's a language-agnostic way how you can do it:
First create a DB table with at least cookie_id and user_id columns. If necessary also add a cookie_ttl and ip_lock. The column names speaks for itself I guess.
On first-time login (if necessary only with the "Remember me" option checked), generate a long, unique, hard-to-guess key (which is in no way related to the user) which represents the cookie_id and store this in the DB along with the user_id. Store the cookie_id as cookie value of a cookie with known cookie name, e.g. remember. Give the cookie a long lifetime, e.g. one year.
On every request, check if the user is logged in. If not, then check the cookie value cookie_id associated with the cookie name remember. If it is there and it is valid according the DB, then automagically login the user associated with the user_id and postpone the cookie age again and if any, also the cookie_ttl in DB.
In Java/JSP/Servlet terms, make use of HttpServletResponse#addCookie() to add a cookie and HttpServletRequest#getCookies() to get cookies. You can do all the first-time checking in a Filter which listens on the desired recources, e.g. /* or maybe a bit more restricted.
With regard to sessions, you don't need it here. It has a shorter lifetime than you need. Only use it to put the logged-in user or the "found" user when it has a valid remember cookie. This way the Filter can just check its presence in the session and then don't need to check the cookies everytime.
It's after all fairly straight forward. Good luck.
See also:
How to implement "Stay Logged In" when user login in to the web application
How do servlets work? Instantiation, sessions, shared variables and multithreading
Well, the original reason I chose OpenID was so someone else could handle as much of the implementation and security of authentication for me.
After looking into OpenID more, it appears there is something called an "Immediate Request" (http://openid.net/specs/openid-authentication-2_0.html#anchor28).
When requesting authentication, the Relying Party MAY request that the OP not interact with the end user. In this case the OP MUST respond immediately with either an assertion that authentication is successful, or a response indicating that the request cannot be completed without further user interaction.
Because of this I think I could just store the user's openID url in the cookie, and use an immediate request to see if the user is authenticated or not. This way I don't have to do anything with my database, or implement any logic for preventing session hijacking of the long-lived cookie.
This method of doing it seems to be the way OpenID suggests to do it with their Relying Party Best Practices document.
I am trying to learn more about JAVA web development. I am mainly focused on trying to understand how data that a user enters, maybe through the course of filling out a multipage form, is managed as the user moves from page to page.
From what I have gathered, you can store data within the session on the server side. I am also learning about cookies which are stored within the browser. Is there a general rule that is used to determine what data should be stored in a cookie vs. when you should store data in a session (session.setAttribute), or are these completely different concepts?
Thanks
The basics of session/cookies are like this.
A session is typically a way for a server to store data about a user. This can be done in a variety of ways from memory, file to database. This session can be used by you store pretty much anything you need to have as the user bounces around your site. It is assigned an ID (the session ID) which you don't usually need to worry about too much. In most web languages you can easily access the user session with some functions without dealing with IDs.
Now since the web is stateless - meaning there is really no way to know that user that visited page A is the same as the one that visited page B then we want to make sure that the user carries their session IDs with them. This can be done in a variety of ways but the most common one is through the use of a session cookie which is a special cookie automatically set by the server that is solely there for passing the session around. It can also be passed in the URL (I'm sure you've seen things like index.php?sessid=01223..) as well as headers and so on.
When most people talk about adding info to a cookie they are not talking about session cookies but about a custom cookie that you specifically set. The only reason that you would want to do that is if you needed to store info beyond the life of the session (which ends when the browser is closed). A good example of that is the "remember me" feature of many sites.
So use sessions unless you need to have something last a long time.
Yes. There are a few rules actually. For one, cookie data is sent by the browser on every request; session data is kept on the server (and not re-transmitted every request). However, usually the session id is used with a coookie. This enables the server to identify the client.
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.
Very basic question.
I have a portal containing several servlets, one of which takes care of logging in (but only as an admin). How do I use HttpSessions between Servlets to know if the admin is signed in?
Thanks in advance!
Whenever your admin users signs in put something like session.setAttribute("admin","true");
check this as session.getAttribute("admin") to see if admin is logged in
set an attribute in session
session.setAttribute("isAdmin",true OR false);
At the login time decide the user type and set it.
I'd store the complete user object in the session.
http://download.oracle.com/javaee/1.3/api/javax/servlet/http/HttpServletRequest.html#getSession()
You can gain access to the session through this method.
If you store the whole user in the session (or the user-id from your database), you can implement a more refined, role-based access later on as your application grows.
greetings
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.