Here, There, and Back Again: Maintaining State Across Domains (cont.)

Technique 3: The Boomerang
Now that you can guide traffic across subdomains on your site, you’re ready for the last little trick: maintaining state across entirely different domains. You may have many reasons for doing this. Perhaps you just acquired another company and need to quickly integrate your two sites. Or maybe you’ve formed a strategic partnership. Or you’re farming out portions of your site to an ASP. Or, like DevX, you organize the site into different domains rather than subdomains, i.e. devx.com, vb-zone.com, asp-zone.com.

The problem is, cookies were designed to be restricted to a single domain. This is important because it ensures privacy for the user. However, in a complex site architecture, you may find yourself unduly restricted, despite having a legitimate reason to share the information.

The goal is to seamlessly submit data to another site without having to prompt the user or ask for yet another form. The most common method is to use a QueryString, like this:

   Response.Redirect("http:///www.mycompany.com/boguspage.asp?name=Justin")

The drawback here, of course, is that the user can see the parameter list, as can anyone else who uses that browser (via the History). To add a layer of security, use the POST method of the form, instead. And since you don’t want to interrupt the user with a Submit request, make it a self-submitting form by using a simple JavaScript method.

Using the Windows XP Developer Center as an example, I wanted to register an alias with a third party discussion board, then return the user to our site to complete our own registration process. Since the discussion board registration takes place after the DevX registration, I decided to use a self-submitting form. Here’s some simple code to POST data to another domain:

   <html>
   <head>
   </head>
   <body onLoad="document.UserReg.submit()">
   <form action="http://www.myothercompany.com/processReg.asp" 
   method="POST" name="UserReg">
   <input type="hidden" name="task" value="RegRequest">
   <input type="hidden" name="alias" 
   value="<%=Alias%>">
   </form>
   </body>
   </html>

The key feature of this example is the onLoad event. Use this event in the <body> tag to execute some JavaScript code as soon as the page loads. In this case, the page submits the UserReg form, found in the next line. Hidden fields let you pass the data with no additional user input. Using this method, you can also begin integrating more advanced security features such as SSL or encrypted form data.

In our scenario, the user needed to return to our site to finish the registration process. This is where the ReturnUrl created in Technique 2 comes in handy. You’ll need to get the specific return protocol from the ASP or developer you’re working with on the other domain, but usually you can simply specify a return URL. In our case, I was able to return users to a single, static URL. I chose to build a page named ReturnUrl.asp, which uses the ReturnUrl cookie (set before the users began their round trip) to redirect them back to their starting point. Thus, I’ve created a seamless loop that is transparent to the user (see Figure 1 for an illustration of the Boomerang).

As with any challenge, alternative solutions for maintaining state exist that rely more on host configurations or heavy programming. But for most applications, using a combination of cookies, redirects and self-submitting forms will help you give your visitors a smooth journey from here to there and back again.


Justin Whitney is a Web Developer with DevX.com and lead developer on the DevX Windows XP Developer Center. Born and raised in Texas, he recently moved to the fabled land of Silicon Valley to see what all the fuss was about. He's still wondering. You can contact him at jwhitney@devx.com.


Back

First Page

Technique 1: Master of your .domain
Technique 2: Where Did I Go Today?
Technique 3: The Boomerang





 TALK BACK
Have you ever used the techniques described in this article? Are you using other methods for maintaining user state information across domains? Join the DevX ASP community at devx.web.asp to get answers, make comments, or help others with their problems.
Click here to Join
Maintaining Session State on Your Web Farm

Maintaining State Within a Website (w/o Cookies or Server-side Scripting)

Cookies Across Domains

Maintaining Session State & Sharing Data across Servers, Domains & the Entire Internet

The Unofficial Cookie FAQ





 
Sponsored Links

Advertising Info  |   Member Services  |   Contact Us  |   Help  |   Feedback  |   Site Map
Jupiterweb networks

internet.comearthweb.comDevx.comClickZ

Search Jupiterweb:

Jupitermedia Corporation has four divisions:
JupiterWeb, JupiterResearch, JupiterEvents, and JupiterImages

Copyright 2004 Jupitermedia Corporation All Rights Reserved.
Legal Notices, Licensing, Reprints, & Permissions, Privacy Policy.

Jupitermedia Corporate Info | Newsletters | Tech Jobs | E-mail Offers

Copyright Information/Privacy Statement