This week's giveaway is in the EJB and other Java EE Technologies forum. We're giving away four copies of EJB 3 in Action and have Debu Panda, Reza Rahman, Ryan Cuprak, and Michael Remijan on-line! See this thread for details.
I am sure most you have heard about (and even contributed to) the solution of this problem. This is my logout code:
in my servlet's doPost() code, before attending to any user request I first check her validity by
This approach works fine. The user however, is able to come back to the "page before logout.jsp" by using browser's back button. Although she is not able to do any processing there because session has already been invalidated, the information of the page is nonetheless visible. I do understand that this is a caching problem. Searching amply on this forum, i pasted the following in the beginning of all my jsps.
I do not know what it does exactly, but common sense and guesswork tells me that it instructs the browser to "not store anything in it's cache".
First question: am I doing it right ? Is this all that has to be done? Simply pasting the above snippet (with offcourse, the server side code to check for user authenticity- i know that is my responsibility). Also, do i need to paste it in ALL jsps. Any way i can use the deployment descriptor here. Or is this page specific. The browser only "does not" cache pages that have this on top.
If yes, then apparently I am not getting the desired results. Now when I click the back button, all I see is that browser specific "page cannot be displayed" message. The surprising part is that this happens even when the user has not logged out and is very much in session.
Important: I placed breakpoints at doGet() and doPost() and i find that clicking back button is not even bringing the control to server. Perhaps that is the reason I see that typical browser message.
Why is it so ? Is it because:
The above snippet will only prevent anything from caching. It will not ask browser "to query the server". Back buttons are not for querying the server. The user has to explicitly hit refresh for that.
Thanks for your reply. I think the problem is not with the code. The snippet suggested by you also works just fine. Just to give you the idea of what is happening.
Before using any scriptlet User logs in --> user does some activity --> user logs out --> logout page --> user clicks back button --> page before logout -->user tries to do some activity --> redirected to "you have logged out. Click here to login" page.
After inserting the scriptlet in every jsp i do not want to be cached User logs in --> user does some activity --> user logs out --> logout page --> user clicks back button --> IE Webpage has expired --> user clicks on refresh -->NOW redirected to "you have logged out. Click here to login" page.
What I want is that instead of that page expired message user should be redirected to the "you have logged out. Click here to login" page. Without needing to hit refresh.
Now you made your requirement clear!!!.
As you might be knowing, we do set these headers to make your application resistant towards well known web-attacks called "Cache Poisoning" & "HTTP Response Splitting" so its a security concern. So once these attributes present in the response header, browser & the proxies cannot cache the response and the default action of the browser is to show your "page expired" message on clicking back button. As far as I know you cannot customize this from server side programming and its not suggested even . Here unless its a public website you can choose to educated the users to not to rely on browser’s back & forth buttons (you may notice most of banking apps don’t allow browser's back & forth and eve refresh buttons on criticcal pages they do invalidate the session if the user use them) .There will be a kind of compromise in terms of perfomance,UI- friendliness when security concerns are implemented.
Through the deployment descriptors (web.xml) you can perform only authentication & authorization I donot think there is support for cache controlling as such. Instead of adding this headers on all the JSPs and Servlets ,do it in Intercepting Filters (Servlet-Filters) so you can plug and unplug based on your need keeping your application components more cohesive.
So once these attributes present in the response header, browser & the proxies cannot cache the response and the default action of the browser is to show your "page expired" message on clicking back button
There is only one of the two cases:
1) setting cache zero just prevents the browser from storing anything. It does not query server by itself unless "asked", by clicking refresh.
2) It is common sense that not having cache would obviously make the browser query server , by itself, without any refresh. If this is true then on server i do have logic to display my custom page.
Do you have any opinion on which of these might be true ?
I have not worked for Banking applications. I believe they do use sophesticated mechanism to sensitize the ordering of navigation by combining Session Tokens & Page Tokens .These tokens generation & validation happens in java at server side and not certainly by client side scripts.This approach is costly interms of development and testing effort.
You are considering only scenarios that involves logout. If you use these cache control headers all over the application you have still issue
say user logs-in navigates through Page1---->Page2--->page3---Page4 now clicking on back button ,you get messages "Page expired" here its not a good idea to display relogin page since their exist a valid session and user can recover by clicking on refresh button.
If this is causing too much trouble , use those headers only for the sensitive pages (login page where user enters credentials, forms where user inputs personal details etc) its more of the level of security required by your application. mine is a reporting solution so we used across all the pages and our customer's are ok to deal with expired pages.
Yes you correctly pointed out that scenario, where despite being in a valid session, user sees page expired while navigating backwards, if I put cache control headers. This is not necessary as per my requirements. I will follow the advice of putting the headers on only the sensitive pages.
And about your question on expired pages: browser wont query the server when you hit the back button until you explicitly click on refresh. If its too much required to refresh the page automatically when you hit the back button..
This is what i was keen on knowing. Thanks for clearing that up. I will see how to make it automatically refresh upon back button click. Meanwhile, there is another query i have posted recently pertaining to request parameter values. Please help on that as per your convenience.