Share via

Cookies and Non-Isolated Content

  • Article

This content is no longer actively maintained. It is provided as is, for anyone who may still be using these technologies, with no warranties or claims of accuracy with regard to the most recent product version or service release.

Typical Web sites use cookies to identify the client between page requests. When a client accesses a page, the page drops a cookie associated with the site's domain that indicates the user has been validated. When the user requests another page from that domain, Microsoft® Internet Explorer passes the cookie value in the HTTP headers and the server then can determine which user is making the request.

A Digital Dashboard presents a new twist on this, because if a Web Part is not isolated, the request for content comes from the dashboard server and not the client computer.

For example, say you create a Web Part that displays the MSN home page (http://www.msn.com/). Users must be able to customize the page, and Internet Explorer must be able to determine the identity of the client. To accomplish this, the following process occurs:

  1. The process begins when the client requests a dashboard for the first time. Internet Explorer sends a URL Get request to the server hosting the dashboard Active Server Pages (ASP). The dashboard ASP receives no cookies from Internet Explorer, because no cookies have been dropped that are associated with the domain of the dashboard ASP.

  2. The dashboard factory renders Web Parts, one of which contains a ContentLink URL pointing to the MSN home page. The dashboard factory requests this URL, but because there are no cookies to forward, it does not send any cookies with the request.

  3. Because the dashboard factory has not passed any cookies in the request, the MSN site returns a generic version of the home page to the dashboard factory.

  4. To customize the Web Part, the user clicks the Customize button in the title bar of the Web Part. The hyperlink associated with this button points to the URL specified in the CustomizationLink property, but the dashboard factory also adds two query string parameters — ReturnURL and PartNamespace. ReturnURL is set to the dashboard.asp (the URL of the dashboard), and PartNamespace is set to the value in the Namespace property of the Web Part. The dashboard factory appends these to any existing query string parameters defined in CustomizationLink or adds a query string if no other query string parameters are defined.

    Note   If the results of the ContentLink URL query is a login screen, that page will not have the correct information for the ReturnURL and PartNamespace parameters. To correct this, the dashboard factory uses a simple case insensitive string replace operation to search for two tokens — _OfficeDashReturnURL_ and _OfficeDashPartNamespace_ — and to replace them with the appropriate values. For example, a Web site that supplies a login screen might return the following HTML:

    <form action="http://www.SomeService.com/login.asp?ReturnURL=_OfficeDashReturnURL_&Partnamespace=_OfficeDashPartNamespace_"  method="POST">
<!-- Login form UI -->
</form>

  5. After the user customizes the MSN home page, the site performs an HTTP redirect (Response.Redirect in ASP) back to the return URL. The site also includes three query string parameters in the redirection response: Partnamespace, UserTicket, and Expires.

    • Partnamespace can contain the same value passed to the site, or the site might modify it. This will be used to qualify the cookie name that the dashboard will eventually drop on the client computer and will be used to determine when to forward the cookie back to the site in future content requests.
    • UserTicket is an opaque string value, which contains any value the site adds. The dashboard factory does not use it. This value will be passed back to the site as the cookie value in future content requests making it possible for the site to determine the identity of the client.
    • Expires is a string specifying the cookie expiration date, and this is in the same format you use when specifying a cookie expiration date in ASP or client-side script, for example "December 31, 2001." If this parameter is not included, the dashboard factory does not give the cookie an expiration value, which means the cookie will be deleted when the user closes the browser.

  6. When the client browser receives the redirect, it requests the redirect URL, which contains the query string parameters mentioned previously. The dashboard factory now receives these parameters.

What happens next will depend on whether the factory page itself is the return URL, or if the factory delegates this to another specialized page. If it is the former, the factory will go through its rendering processing first, but it will make sure to forward the UserTicket cookie back to any ContentLink that has the same namespace value as the PartNamespace return parameter. In addition, it will include a new cookie in the returned page. The cookie's name will be <PartNamespace>:UserTicket, and its value will be the value returned in the UserTicket parameter.

If the factory uses a specialized page to handle the ReturnURL, that page first returns the cookie described previously and then redirects back to the main dashboard ASP.

  1. Because the Web site has returned the UserTicket cookie value, the dashboard can forward this cookie value when requesting the URL in ContentLink. The algorithm for this is as follows:

    • When requesting a ContentLink URL
    • If any cookies exist whose name starts with Currentwebpart.Namespace
    • Forward the cookie in the HTTP_COOKIE header under the name "UserTicket"

    Note   The cookie name the site receives is just UserTicket without the namespace. This makes it easier to locate.

  2. The MSN site retrieves the UserTicket cookie and any other cookies that the Web Part's client-side script might have dropped under the same namespace. The MSN site uses this ticket value to look up the user's personal settings and information and to generate specific content for that user.

Internet Explorer receives the cookie and stores it for future requests.

See Also

Developing a Digital Dashboard Using Web Parts | Guidelines for Building Good Web Parts | The CustomizationLink Property | The PartStorage Property | Cookies