Dear Wiki user, You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification.
The following page has been changed by LaurieHarper: http://wiki.apache.org/struts/BrowserBackAndSecurity New page: == Managing the Browser Back Button == Two commonly asked questions on the Struts Users mailing list are how to prevent the user from seeing stale data when they hit the browser's 'back' button, and how to prevent them from seeing a secured page by hitting the back button after logging out. It turns out that these issues are related, and the solution to the latter builds on the solution to the former. === Browser Caching Behaviour === When you ask your browser to display a web page it has several options for how to proceed, depending on whether the page has been requested before, whether it has a copy cached locally, and what caching policies affect that page. Assuming the browser has displayed a page at least once, the options are (roughly speaking): * display the page from the browser cache * ask the server if there is a newer version of the page than what's in the cache. If not, display the cached copy; otherwise, fetch the updated copy * fetch a fresh copy every time Browsers can usually be configured to force the use of any of these strategies all the time. Typically, however, the behaviour depends on hints the browser receives from the server whenever it requests a page. These hints tell the browser whether it is allowed to cache the page at all and, if so, under what circumstances and for how long. By default, a browser will do its best to cache pages and avoid fetching fresh copies, so it can display them more quickly when asked to do so. === Avoiding Stale Date: Cache Control === To prevent the user from seeing stale data when they hit the back button, you need to tell their browser not to cache the page. You do this by including cache control 'hints' -- special HTTP headers -- in the response to each request. There are a number of different 'hints' you can supply, and different browsers (and HTTP proxies) respect different hints, so you need to supply several to achieve the desired result in all circumstances. Specifically, you need to set the `Pragma`, `Cache-Control`, and `Expires` headers, as follows: {{{ ??? }}} You can do this every time in your actions or JSPs, but that quickly gets tedious. Fortunately, Struts provides a way to do this automatically, by setting `nocache="true"` on the `controller` element in `struts-config.xml`: {{{ <controller nocache="true" processorClass="... }}} With this set, responses from your Struts application will include the cache-control headers and the browser will never cache them. As a result, when the user hits the 'back' button, the browser will always request a fresh copy of the page and will never be presented with a cached, stale copy. === Enforcing Page Security === The problem with with users accessing secured pages by hitting the back button after logging out is partially solved by implementing cache control as described above, but that is only part of the solution. With cache control in place, the browser will request a fresh copy of the secured page but it is up to the application to determine that the user is no longer logged in and refuse to display the requested page. There are many ways of securing pages in a web application. Approaches include Container-managed security, using a Servlet Filter to pre-process every request, or implementing security checks in your individual actions (among others). We wont cover the details here, just note that you need some form of '''per-request''' access control in place. Every time a user requests a page, a check needs to be made (by the Servlet container or by your application) that the user is logged in and has permission to see the page. With that in place, together with cache control, you can be assured that when the user logs out they will not be able to return to a secured page using the back button. Typically, you will base your access control on the user session. In that case, logging the user out is simply a matter of invalidating the session (calling `Session.invalidate()`). If your access control mechanism uses something other than the session -- such as a cookie -- to track a user's authenticaion status, you will need to manage that appropriately. For a good introduction to implementing security and access control in a Struts-based web application, see the following resources: * TODO: add some links to appropriate tutorials / articles --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
