logout mechanism

[Alan Shiers]

Hi there,

I'm working on a web app that involves a Login procedure. When the user fills out a form consisting of username and password, the form data goes to a servlet that sets an attribute in the Session object. So far, so good.

For the logout mechanism, I've created another servlet that simply grabs the Session object and removes the attribute. When the user clicks on the logout menu item, a jquery function calls LogoutServlet, which does its thing, then the user is redirected back to the home page. All this works except...
now on the home page, if I click on the back button on the browser, I'm returned to the previous page. That shouldn't happen. At the top of my JSP page I run a test like so:

UserBean currentUser=((UserBean)(session.getAttribute("currentSessionUser")));

//Prevent people from having direct access to this page.
if(currentUser == null)
{
response.sendRedirect("../index.jsp");
}

Since I removed the attribute "currentSessionUser" from the Session object when I logged out, the variable currentUser should now be null. For some reason, it isn't since I'm able to click the back button on the browser and return to the JSP page without any problem. The logout mechanism isn't working as I had hoped.
Please advise.

Alan

public class LoginServlet extends HttpServlet {
  protected void doGet(HttpServletRequest request, HttpServletResponse response)
            throws ServletException, IOException {
        doPost(request,response);
    }
  protected void doPost(HttpServletRequest request, HttpServletResponse response)
  throws ServletException, IOException {
	  try{
          UserBean user=new UserBean();
          user.setUsername(request.getParameter("uname"));
          user.setPassword(request.getParameter("upassword"));
          user=UserDAO.login(user);
         
          if(user.isValid()){
              HttpSession session=request.getSession(true);
              session.setAttribute("currentSessionUser", user);
              //response.sendRedirect("search/csa.jsp");                
          }
          else{
              //response.sendRedirect("index.jsp");
              response.setContentType("text/html");
        	  PrintWriter out = response.getWriter();
        	  out.print("No Match");
          }
      }
      catch(Throwable  theException){
          theException.printStackTrace();
          
      }  
  }
}

public class LogoutServlet extends HttpServlet
{
	protected void doGet(HttpServletRequest request, HttpServletResponse response)
    throws ServletException, IOException {
      doPost(request,response);
    }
    protected void doPost(HttpServletRequest request, HttpServletResponse response)
      throws ServletException, IOException
    {
    	HttpSession session=request.getSession();
    	session.removeAttribute("currentSessionUser");
    	System.out.println("removed user");
    }
}

[Ulf Dittmer]

Clicking the back button frequently causes the browser to display the page from cache, rather than getting it fresh from the server.

Note that login and logout are actions should always be done via POST, not GET, so you should not treat those interchangeably like your code now. If you then use the PRG pattern to get to (say) the login page after logout this problem should not occur.

[may naren]

Ideally, you should use below code in your jsp to prevent the browser from caching the page. There are 3 variants - in meta tags or in the jsp scriplets or in the servlet sending back the response

in meta tags like :
<META HTTP-EQUIV="CACHE-CONTROL" CONTENT="NO-CACHE">
<META HTTP-EQUIV="EXPIRES" CONTENT="Mon, 22 Jul 2002 11:12:01 GMT">
<META HTTP-EQUIV="PRAGMA" CONTENT="NO-CACHE">

OR in scriplets like :

<%response.addHeader("Cache-Control","no-cache");%>

[Bear Bibeault]

The use of scriptlets in 2013, a dozen years after they've been obsolete, is not advised.

[Alan Shiers]

OK. I still have an issue with this. Here is what I've done so far:

1. I fixed up the servlets getting rid of the doGet() methods and recompiled.
2. For both browsers IE and FireFox I've cleared out all cache.
3. In all JSP files that I don't want to cache I added the META tags as recommended

When I retest the sequence (logging in, and being presented with the JSP page named csa.jsp, then logging out and returned to home page index.jsp) I can still click the back button and return to the JSP page csa.jsp that tests for the presence of the Session attribute "currentSessionUser".

<%
UserBean currentUser=((UserBean)(session.getAttribute("currentSessionUser")));

//Prevent people from having direct access to this page.
if(currentUser == null)
{
response.sendRedirect("../index.jsp");
}

...
%>

By rights, currentUser should be null! This csa.jsp page does have the META tags mentioned earlier, therefore this page should not be cached.

Am I missing something?

Also, I'm seeing comments, actually warnings, against the use of Scriptlets. What's up with that? I haven't been living under a rock or anything and this is the first time seeing these types of comments. Did someone discover a major flaw with Scriptlets or something? What's wrong with them?

Alan

[Ishan Pandya]

Alan Shiers wrote:

When I retest the sequence (logging in, and being presented with the JSP page named csa.jsp, then logging out and returned to home page index.jsp) I can still click the back button and return to the JSP page csa.jsp that tests for the presence of the Session attribute "currentSessionUser".

Alan

You may find some information from NoCacheHeader

Alan Shiers wrote:

Also, I'm seeing comments, actually warnings, against the use of Scriptlets. What's up with that? I haven't been living under a rock or anything and this is the first time seeing these types of comments. Did someone discover a major flaw with Scriptlets or something? What's wrong with them?

Alan

Scriptlets are not used in JSP. This is avoid bad design i.e to separate java code and designing , simple debugging, code maintenance and mainly for designer's.

[Alan Shiers]

Well, in my JSP pages I have now both the META tags and the response headers set:

response.setHeader( "Pragma", "no-cache" );
response.setHeader( "Cache-Control", "no-cache" );
response.setDateHeader( "Expires", 0 );

Still, when I use the Back button on the browsers I'm able to return to the JSP page. I know it's not suppose to happen, but it does. Any other suggestions?

Alan

[Ulf Dittmer]

I wouldn't say it's not supposed to happen, because:

Ulf Dittmer wrote:Clicking the back button frequently causes the browser to display the page from cache, rather than getting it fresh from the server.

It's something that the web app does not have complete control over. Are you now doing the PRG thing?

[Alan Shiers]

From what I've seen about the RPG thing, is that I've been doing that all along. I've pointed out twice now that I do a check on the csa.jsp page for the presence of the attribute "currentSessionUser". The LogoutServlet removes this attribute, plus I've added the line session.invalidate() after I've removed the attribute. csa.jsp now looks like this:

<%
UserBean currentUser=((UserBean)(session.getAttribute("currentSessionUser")));
ArrayList<Profile> profiles = new ArrayList<Profile>();
//Prevent people from having direct access to this page.
if(currentUser == null)
{
  response.sendRedirect("../index.jsp");
}
else
{
  int userid = currentUser.getUid();
  Database db = new Database("search_assistant");
  String query = "SELECT id, name FROM profiles WHERE uid=" + userid;
  String[][] results = db.executeSelect(query,2); 
  if(results != null)
  {
    int length = results.length;
	Profile p = null;
	for(int i = 0; i < length; i++)
	{
	  p = new Profile();
	  for(int j = 0; j < 2; j++)
	  {
	    if(j == 0)
	      p.setId(Integer.parseInt(results[i][j]));
		else if(j == 1)
		  p.setName(results[i][j]);		
	  }
	  profiles.add(p);
	}
  } 

  response.setHeader( "Pragma", "no-cache" );
  response.setHeader( "Cache-Control", "no-cache" );
  response.setDateHeader( "Expires", 0 );  
%>


<!doctype html>
<html lang="en">
<head>
  <meta charset="utf-8" />
  <meta http-equiv="cache-control" content="max-age=0" />
  <meta http-equiv="cache-control" content="no-cache" />
  <meta http-equiv="expires" content="0" />
  <meta http-equiv="expires" content="Tue, 01 Jan 1980 1:00:00 GMT" />
  <meta http-equiv="pragma" content="no-cache" />
  <title>...</title>

  ...

To me, that is the RPG pattern, isn't it?

Alan

[Ulf Dittmer]

Not at all - there is no redirect.

[Alan Shiers]

Ulf Dittmer wrote:Not at all - there is no redirect.

I just showed you the redirect:

if(currentUser == null)
{
response.sendRedirect("../index.jsp");
}

[Ulf Dittmer]

I see, sorry, I missed that. And this page is reached via a POST? And you can still just click the back button and get back to it?

[Ulf Dittmer]

Maybe I should elaborate: the issue isn't with this page. If the browser never asks for the page again, then it doesn't matter what checks are in it - they will never be executed. That's why it's crucial that the logout page be reached via a POST - because a browser will not just redisplay that from the cache.

Nonetheless, you should put a "return" after the redirect to prevent the rest of the page from being executed, like you would in a servlet (where such control logic properly belongs).

[Alan Shiers]

Ulf Dittmer wrote:I see, sorry, I missed that. And this page is reached via a POST? And you can still just click the back button and get back to it?

The servlets LoginServlet and LogoutServlet are reached via POST, yes. What's happening, that I can see, is that even though I set the headers and META tags to stop the browsers from caching, they're doing it anyway. When I test, I first clear the browsers of their cache, close them down, relaunch them and run the test again. That Back button is a real pain in the $%^&*, if you know what I mean.

My login.jsp page has some jquery in it that contacts the LoginServlet which looks like this:

$('#login').click(function(){
		    var name = $('#uname').val();
			var pwd = $('#upassword').val();
			if(name == "")
			{
			  alert("You must provide a user name.");
			  return;
			}
			if(pwd == "")
			{
			  alert("You must provide a password.");
			  return;
			}
		    $.post('../LoginServlet', {uname:name,upassword:pwd}, function(data) {
			  if(data == "No Match")
			  {
			    alert("There is no match for the combination\nusername and password provided.\nPlease try again.");
			  }
              else
              {
                window.location.href = "csa.jsp";
              }			  
		    });
		  });
		});

Likewise, my csa.jsp page has a similar jquery function for the logout menu:

$('a#logout').click(function(){
	    $.post('../LogoutServlet');
	    window.location.href = "../index.jsp";
	  });

I don't know if any of this helps or not, but there it is.

[Alan Shiers]

OK...I finally found something that actually works! After much research on the internet, I wound up creating a filter class:

import java.io.IOException;
import javax.servlet.Filter;
import javax.servlet.FilterChain;
import javax.servlet.FilterConfig;
import javax.servlet.ServletException;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;
import javax.servlet.http.HttpServletResponse;



public class NoCacheFilter implements Filter 
{
	public void init(FilterConfig config) throws ServletException {
        // If you have any <init-param> in web.xml, then you could get them
        // here by config.getInitParameter("name") and assign it as field.
    }

    @Override
    public void doFilter(ServletRequest req, ServletResponse res, FilterChain chain) throws IOException, ServletException {
    	HttpServletResponse hsr = (HttpServletResponse) res;
        hsr.setHeader("Cache-Control", "no-cache, no-store, must-revalidate"); // HTTP 1.1.
        hsr.setHeader("Pragma", "no-cache"); // HTTP 1.0.
        hsr.setDateHeader("Expires", 0); // Proxies.
        chain.doFilter(req, res);
    }

    @Override
    public void destroy() {
        // If you have assigned any expensive resources as field of
        // this Filter class, then you could clean/close them here.
    }

}

I added the following to the web.xml file:

<filter-name>noCacheFilter</filter-name>
<filter-class>com.tacticalenterprisesltd.NoCacheFilter</filter-class>
</filter>

<filter-mapping>
<filter-name>noCacheFilter</filter-name>
<url-pattern>/search/*</url-pattern>
</filter-mapping>

On all my JSP files I removed all META tags and response Headers regarding cache. I cleared all browsers of cached files, restarted Tomcat, reopened the browsers and ran the test. Finally, the browsers aren't caching. I still don't know why they were still caching prior to the implementation of the filter class, but they were despite the fact that the instructions were there on every JSP page. I'm just thankful I found something that works. Thanks for all your advise guys.

Alan

[Bear Bibeault]

A filter is a great way to accomplish this, as opposed to cutting and pasting the code into multiple servlets (or worse, putting Java code in a JSP! )