Same Cookie Domain Workaround
OracleAS Portal
Developer Kit (PDK)
Sharing Session Cookies Not Allowed in PDK-Java
Release 2
| Last Updated: |
June 3, 2004 |
| Status: |
Production |
| Version: |
PDK Release 2, (9.0.2 and later) |
Contents
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.
- 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.
- 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
- 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.
- 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.
- 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
- 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:
- use longer cookie names that are qualified with the name of the application
and ensure application names are unique
- 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.
- 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.
| 
Bookmark
