Win a copy of Java Concurrency Live Lessons this week in the Threads forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

logout mechanism  RSS feed

 
Alan Shiers
Ranch Hand
Posts: 237
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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

 
Ulf Dittmer
Rancher
Posts: 42970
73
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Greenhorn
Posts: 2
Java
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Author and ninkuma
Marshal
Posts: 65833
134
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The use of scriptlets in 2013, a dozen years after they've been obsolete, is not advised.
 
Alan Shiers
Ranch Hand
Posts: 237
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 228
Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 237
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Rancher
Posts: 42970
73
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 237
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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:



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

Alan
 
Ulf Dittmer
Rancher
Posts: 42970
73
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Not at all - there is no redirect.
 
Alan Shiers
Ranch Hand
Posts: 237
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Rancher
Posts: 42970
73
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Rancher
Posts: 42970
73
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 237
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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:



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



I don't know if any of this helps or not, but there it is.
 
Alan Shiers
Ranch Hand
Posts: 237
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
OK...I finally found something that actually works! After much research on the internet, I wound up creating a filter class:



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
Author and ninkuma
Marshal
Posts: 65833
134
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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! )
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!