Options for Handling the Session ID that Appears in the URL on the Initial Loading of a Portal Application

Introduction

By default, a session ID parameter appears in URL when a WebCenter Portal (WCP) application is first accessed.  If cookies are enabled in the browser, this parameter no longer appears in the URL. Some users and customers have expressed concern over this behavior, since the session ID is readily available in the URL.  This article explains why the parameter is there and presents options for how to handle the behavior.

Main Article

This article assumes a basic working knowledge of URLs, cookies, and HTTP sessions.  In short, an HTTP server creates a session for each new connection from a browser, using that session ID to maintain state with the browser over multiple interactions.  Since the session ID identifies the state of the application, the interaction between the browser and server should limit external access to that session ID.

Cookies

Cookies are snippets of data saved on the client, and managed by the client browser. When a session is started between the browser and a server, the generated session ID is typically saved in a browser cookie.  This is the default WCP behavior.  Some customers, however, do not support cookies at all, or only allow cookies after the user has formally consented.  Without cookie support, either at all or initially, the session ID is communicated as a URL parameter.

URL Rewriting

In a WCP application, URL rewriting is enabled by default.  This allows for cookies being disabled in the browser, since part of the URL rewriting logic includes the session ID as a URL parameter, as needed.  As described in a blog post, URL rewriting can be disabled completely by adding the following entry in the weblogic.xml file:

<url-rewriting-enabled>false</url-rewriting-enabled>

The impact of disabling this, however, is that the session ID is never supplied as a URL parameter.  This means that cookies are always required for the application to maintain session state.

Multiple Web Applications

To work around cookies always being required, when URL rewriting is disabled, there would need to be two similar web applications. One of the web applications would be designed to work with cookies enabled, and the other web application would be designed to work with cookies disabled.  Logic in the initial process to log in would determine which web application would be best for this user.

Session Regeneration

As mentioned above, a session ID parameter appears in URL when a WCP application is first accessed.  After the user logs in, WebLogic Server (WLS) generates an entirely new session, with a new session ID.  If cookies are enabled in the browser, the new session ID will not appear as a URL parameter.  This speaks to the concern about the initial session ID appearing in the URL. That initial session ID value is discarded, and the regenerated session ID does not appear in the URL.

Summary

The session ID that appears in the URL when a WCP application is initially loaded can be disabled, by turning off URL rewriting, but this requires cookies for the rest of the application.

To allow for cookies being enabled or disabled, separate web applications would be required with a redirect based on the particular user situation.

After logging in, the session ID is regenerated, so the session ID that appears in the initial URL is discarded.  This should eliminate the concern over the session ID being visible in the URL.

Add Your Comment