Caching considerations
Information that is protected by access control, and is therefore restricted to a limited set of people, needs special consideration when served from an access control agnostic cache. These considerations especially apply to server side caches but we also need to consider local browser caches.
Browser caches usually have no issues unless the computers are shared between multiple users with different levels of access. If you access WebSphere Portal from a shared computer, it is important to realize that all users who have access to the computer can access content cached in the local browser cache. To prevent this from happening, do not enable public or private caching of the content. Caching is disabled by default.
Depending on the type of browser we are using, we can still experience information leakage from shared computers, even if caching is completely disabled, because some browsers serve content that is accessed by clicking the browser's Back button from a separate history cache that is not affected by HTTP caching directives. As a result, if you click the Back button, we may see content generated from the previous user even if the previous user performed a logout. To prevent this from happening, the markup rendered on logout should explicitly clear the browser's history cache, which typically requires browser-specific script coding, or display a message to close all browser windows after logout. History cache can typically be disabled in the browser but it may be activated by default.
The WebSphere Portal Performance Tuning Guide provides information about caches for WebSphere Portal and Web Content Manager. After setting up the environment, review the tuning guide to learn more about stand-alone and cluster tuning, and then read about both WebSphere Portal and Web Content Manager caches.