# Oracle9iAS Portal Developer Kit (PDK)
Sharing Session Cookies Not Allowed in PDK-Java Release 2

Creation Date: | May 8, 2003
Status: | Production
Version: | PDK Release 2, (9.0.2 and later)

### Contents

- Overview
- Cookies, Oracle Portal and Web Providers
  - Cookie Basics
  - Normal Portal/Web Provider Operation
- Sharing Cookies using "Same Cookie Domain" Functionality

- Pitfalls of Sharing Cookies (All PDK-Java Releases)
- Avoiding the Pitfalls of Sharing Cookies
- Restrictions Introduced with PDK-Java Release 2

## Overview

In the 3.0.9 release, Oracle Portal provided a facility that allowed providers to share cookies with other applications under certain conditions. With PDK-Java release 1, web providers could use this facility to share the cookie that identifies a web provider's Servlet session. This made it possible for a web provider and a related web application to share the same physical Servlet session and therefore share data within that session. However, with PDK-Java release 2, this is no-longer possible. The purpose of this document is to describe the general issues associated with sharing session cookies and the specific restrictions that were introduced with PDK-Java release 2

## Cookies, Oracle Portal and Web Providers

This section describes the basic rules of cookie management and the interactions between your web browser, Oracle Portal and a web provider.

### Cookie Basics

Web browsers have built in rules for receiving and sending cookies. When a browser makes a request to a web server and the web server returns cookies with the response, the browser will only accept a cookie if the domain associated with the cookie matches that of the original request. Similarly, when a browser makes a subsequent request, it will only send those cookies whose domain matches that of the target web server.

These rules are designed to ensure that information encoded in cookies is only "seen" by the web server(s) that the originator of the cookie intended. These rules also ensure that the cookie cannot be corrupted or imitated by another server. By default, the domain associated with a cookie exactly matches that of the server that created it. However, it is possible to modify the domain at the time the cookie is created. Relaxing the cookie domain increases the scope of the cookie's visibility making it available to a wider "audience" of web servers.

For example, if a cookie is created by a.us.oracle.com, it's domain will usually be set to a.us.oracle.com. This means that the browser will only send the cookie to a.us.oracle.com. It will never send it to any other servers. However, if at the time of creation, the domain of the cookie is set to .us.oracle.com, the browser will send the cookie to any server whose domain falls within .us.oracle.com. such as portal.us.oracle.com, provider.us.oracle.com, app.us.oracle.com etc

### Normal Portal/Web Provider Operation

In the Web Provider architecture, web providers are distributed components. When a request for a portal page is received by the Portal it proceeds to request portlet content, in parallel, from individual providers. The providers may be local to the portal (database providers) or distributed (web providers). In this architecture, the portal is acting a client to the web provider - just as a browser acts as a client to a web server. The Portal generates requests for content, sends the requests to a web provider and then processes the response.

During normal operation, any cookies created by a web provider when initSession() is called are returned to the Portal. The Portal stores the cookies in the user's portal session and returns them to the web provider with each portlet render request within that user's session. Since the Portal is acting as the browser in this situation, the scope of the web provider cookies does not need to be modified. If the web provider needs to make a cookie visible to other web servers it can do so using the "Same Cookie Domain" functionality of the Portal.

## Sharing Cookies using "Same Cookie Domain" Functionality

If a web provider needs to share cookies with a related web application the portal administrator checks the "Same Cookie Domain" checkbox in the Provider Registion or Edit Provider screen. This tells the Portal that it should not manage the cookies itself, but instead should forward any cookies created by the web provider to the user's browser. In order for the browser to accept these cookies, the cookie domain must be scoped correctly so that the domain associated with the cookie includes:

- the Portal's web server (eg portal.us.oracle.com)
- the web provider's server (eg provider.us.oracle.com)
- the target web application's server (eg app.us.oracle.com)

Based on this example, the scope of any cookies created by the web provider must be relaxed to ".us.oracle.com". Now, when the Portal sends the web provider's cookies to the browser they will be sent with any request to any web server that falls within the ".us.oracle.com" domain. This allows a web provider to include deep links to a related application and for the web provider's cookies to be sent from the browser to that application.

The most common usage of this mechanism is to share information - either by including the values to be shared in the cookie itself or by using the value of the cookie as a key that can be used to access shared data. If the cookie being shared is the servlet session cookie and the web provider and related application are deployed in the same JVM it is even possible for the web provider and web application to share the contents of the same physical servlet session and consequently share any state it contains.

This mechanism has also been used by some customers to allow tighter integration between a web provider and an external application. When you access the external application via a deep link shown in a portlet, the existence (and content) of the shared session is used to automatically authenticate you with the external application thereby giving the effect of single sign on (SSO). However, if you access the external application first, you would have to login to the external application using the external application's login screen. If you subsequently access the portal (within the same browser session) you would also have to login to the portal so this is not a true single sign on solution.

### Pitfalls of Sharing Cookies (All PDK-Java Releases)

Since the domain of a cookie must be relaxed in order for it to be shared, the cookie becomes visible to a potentially large number of other web servers that would ordinarily never "see" the cookie. This can cause problems if any applications running on these other web servers uses a cookie whose name matches the name of the cookie that is being shared.

Suppose you have 2 unrelated web applications deployed on different web servers. The first is a web provider deployed on provider.us.oracle.com and the second is a normal web application deployed on other.us.oracle.com. The web provider uses the "same cookie domain" functionality and scopes its cookies to ".us.oracle.com" and both applications create a cookie called MYCOOKIE.

1. You start a new browser session by opening your web browser and access the web application at other.us.oracle.com. During that interaction the application creates a cookie called MYCOOKIE that is scoped to other.us.oracle.com.
2. You interact with this application for some time and the cookie MYCOOKIE is sent to other.us.oracle.com with each request. Everything works normally
3. Within the same browser session, you then access a Portal page containing a portlet from the web provider at provider.us.oracle.com. The cookie created by other.us.oracle.com is not sent to the portal because its domain does not match that of the portal's web server. The web provider creates a cookie, also called MYCOOKIE, that is scoped to .us.oracle.com because it needs to share that cookie with a related application. Since the web provider was registered with the "same cookie domain" checkbox checked, MYCOOKIE is sent to the browser. The browser now has 2 cookies called MYCOOKIE - it knows the cookies are different because they have different domains so it keeps both.
4. You now go back to the application at other.us.oracle.com. This time, when you access the application, both the cookies called MYCOOKIE are sent with the request. The web application is expecting only 1 cookie so it just reads the first cookie it finds (which may or may not be the correct one). At this point, the behavior of this web application is undefined - it may be able to detect that the cookie does not contain the correct value, or (more likely) it will try to use the value contained in the cookie an fail at some point with an unexpected error. When someone tries to debug this application, they will not be able to reproduce the problem unless they also access the portal as in step 3 above.
5. You proceed with your work as normal and periodically see "strange" behavior or errors in the application at other.us.oracle.com, but no-one can reproduce the problem
6. Eventually, the cause of the problem may be found - but it will take a lot of effort to find it.

If the cookie being shared in the example above was a servlet session cookie, then you would see intermittent loss of session data in the application running at other.us.oracle.com or any other web application running on a web server in the .us.oracle.com domain

As you can see, cookie collisions like this are difficult to detect could, potentially, affect anything except the web provider that is causing the problem - this makes the problem even harder to track down.

> NOTE: It is generally recommended that you scope cookies as tightly as possible and not use the "same cookie domain" functionality unless you really have to.

### Avoiding the Pitfalls of Sharing Cookies

Generally, you can avoid cookie name collisions like the one above by ensuring that cookie names are as unique as possible. You can do this by:

1. use longer cookie names that are qualified with the name of the application and ensure application names are unique
2. If you are using PDK-Java Release 1 (JServ) and you want to share the Servlet session cookie, always run web providers that generate session cookies with a relaxed scope in their own, uniquely named, Servlet Zone - with only one web provider per servlet zone. This avoids collisions because the name of the servlet zone is encoded into the JServ session cookie name.
3. Don't share cookies - use other approaches to share data between applications

### Restrictions Introduced with PDK-Java Release 2

PDK-Java Release 2 was designed to be used with Oracle Containers for Java (OC4J) which supports the Servlet 2.3 specification. The Servlet 2.3 specification does not use the concept of Servlet Zones. Instead it partitions web applications running in the same application server using a different mechanism. This mechanism makes use of the ability to scope cookies not only to a domain, but also to an application path. The path being the URI of the owning web application. The use of both the domain and path now means that cookies can be scoped very tightly to a specific application running on a specific web server.

The Servlet 2.3 Specification also dictates that Servlet session cookies be named "JSESSIONID". This was introduced into the specification to simplify the configuration of Load Balancing Routers (LBRs) and allow them to load balance based on a commonly available cookie.

The problem here is that in order to make a cookie sharable, both the domain and the path scopes must be relaxed, effectively removing all the controls that would otherwise prevent Servlet session cookie collisions. This makes it impossible to safely expose the Servlet session cookie of a web provider to the browser. Doing so will almost certainly break other applications running in the same domain.

##

Revision History: |
Revision No | Last Update
1.0 | May 8, 2003

Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA 94065, USA http://www.oracle.com/ | Worldwide Inquiries: 1-800-ORACLE1 Fax 650.506.7200 | Copyright and Corporate Info