|Last Updated:||June 3, 2004|
|Version:||PDK Release 2, (9.0.2 and later)|
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
This section describes the basic rules of cookie management and the interactions between your web browser, Oracle Portal and a web provider.
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
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.
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:
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.
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.
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.
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:
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.
| Oracle Corporation
500 Oracle Parkway
Redwood Shores, CA 94065, USA
| Worldwide Inquiries:
|Copyright and Corporate Info|