URL rewriting

With URL rewriting, all links that are returned to the browser or that get redirected have the session ID appended to them. When the user clicks these links, the rewritten form of the URL is sent to the server as part of the client's request. The servlet engine recognizes the session ID in the URL and saves it for obtaining the proper object for this user. To use URL rewriting, HTML files (files with .html or .htm extensions) cannot be used for links. To use URL rewriting, JSP pages must be used for display purposes. A session with URL rewriting expires when the customer logs off.

Because URLs returned to the browser contain session IDs, another user with access to the browser history (for example, on a shared computer) could potentially gain access to sensitive information exchanged during a session-if the session has been left active. To prevent such unauthorized access, site developers should consider adding a notice to their site urging customers to always log off at the end of their visit, thereby ending (expiring) their session, particularly on a shared computer.

WebSphere Commerce dynamic caching and URL rewriting cannot interoperate. With URL rewriting turned on, you need to disable WebSphere Commerce dynamic caching.

The administrator can choose to support either only cookie-based session management or both cookie-based and URL-rewriting session management. If WebSphere Commerce only supports cookie-based session management, customers' browsers must be able to accept cookies. If both cookie-based and URL rewriting are selected, WebSphere Commerce first attempts to use cookies to manage sessions. If the customer's browser is set to not accept cookies then URL rewriting is used.

For more information about WebSphere Commerce session management see:

http://publib.boulder.ibm.com/infocenter/wchelp/v6r0m0/index.jsp?topic=/com.ibm.commerce.admin.doc/concepts/csesmsession_mgmt.htm

xxxx