Protected Cross-Domain Access with Dojo’s windowName

By on August 18, 2008 3:25 pm

The new windowName module ( now includes support for resource authorization as Neil Roberts described in his article on xauth. Now the windowName module can be used with a enabled resources for simple (direct) access as well resources that require an authorization step.

To request a protected access resource, you still use the send method, but indicate that the resource may need authorization by including an authElement property that refers to a DOM element which can be used for displaying authorization. To access a protected resource, first create an element that will be used for authorization:

Now we can send the request for the resource:

var authElement = dojo.byId("authTarget");"GET",{
  url: "",
  authElement: authElement // this will cause send to use the authorization protocol

Here is a demonstration of using the windowName module to connect to a remote authorized resource (click the “get data with authorization” button within the demo).

From the Server

If you provide access to a protected resource for a cross-domain site, you should generally require authorization from the user, such access should not happen without the user’s consent. A request for protected access resource with the windowName module is indicated by a request with the URL query parameter windowname=auth. The client should (and Dojo’s windowName does) set this query parameter. This windowname=auth parameter, inserted in the URL by the client, can be used by the server so that it knows that it can authorize the user before setting the property and returning a response to the requesting page. If a request for a protected resource without this parameter is received, the server can simply return a response indicating that this was an unauthorized access attempt (401 status with an appropriate message).

When the server receives a request with the windowname=auth parameter, it can return a page that will authenticate the user if necessary, and ask the user if they authorize this site to access the resource. Once authorization has been confirmed, the data can be provided to the calling site by first getting the current value of (this is the return URL), setting the property to the data to be returned to the calling site, and then changing location of the return URL (original value of For example:


Note: make sure the resource’s content type is text/html so the browser properly interprets the page.

Improving the User Interface

If the target resource has already been authorized (perhaps previously in the session), the requested resource may return data immediately upon loading. In these situations, you may not want any visible user interface until it has been determined that the resource needs authorization interaction from the user. The method provides a callback argument so that you can be notified when authorization is actually needed. Let’s walk through the request and authorization process:

  • First the client mashup application makes a request for a resource through the windowName module and this is sent to the server.
  • The response is received from the server. If the resource is already authorized for this web site and user, than the property can be set immediately and the client application can proceed quietly without bothering the user at all, and the user should not be shown any authorization user interface elements.
  • If the response requires authorization (or authentication), then the authorization user interface elements should be displayed for the user. Note that the user interface for authorization does not need to be displayed until authorization has began.
  • Once authorization is complete, the authorization user interface can be hidden, the user can return to focusing on the client application.

By only displaying authorization user interface as needed, we can create a more minimal compact user interface. To do this, we will start with the authorization element being hidden:

And we can use the callback to display the authorization area when appropriate:

var authElement = dojo.byId("authTarget");
var deferred ="GET",{
    url: "",
    onAuthLoad: function(){
       //authorization page has loaded, make the auth UI visible now = "block";
    // this will cause send() to use the authorization protocol
    authElement: authElement
deferred.addCallback(function(result){ = "none"; // hide UI again now that we are done
    ... process the result ...


Using this authorization protocol leverages the native sandboxing and inter-frame messaging capabilities of existing browsers to provide a significantly more secure and convenient mechanism for accessing protected cross-domain resources. This approach is more convenient because web services can utilize cookies so that authentication does not have to be repeated, and authorization can take place in page without requiring page redirections. The user can simply click a button to authorize a request. This approach is more secure because users do not have to provide their credentials to third party mashup sites giving them full access to their information. Web services can provide granular authorization levels for resource access. Far from a hack, this techniques utilizes the intentional security mechanisms in the browser to provide proper security boundaries between domains so that data can be safely shared without vulnerability to exploits. For resources that require authorization, this technique is actually simpler and more well integrated with the browser than the new cross-site XHR capabilities that will require custom user interaction or redirection schemes for secure authorization (although these new capabilities are still extremely valuable, especially for public resources).

The xauth library provides simple access to the authorization protocol and can be used with any JavaScript library. Dojo’s windowName module provides tight integration with Dojo’s IO system. These client libraries further increase the accessibility of this new technique. As web services adopt this approach, we can easily utilize cross-domain data interaction with true security barriers between the client and server. Consumers are protected from malicious scripts from the web service, and the web service can protect itself with proper authorization mechanisms.


  • Neil


    How much data can be passed this way (ie, is there a size limit on the property in any/all browsers)?



  • Pingback: SitePen Blog » Security in Ajax()

  • Neil


    Thanks for the answer re size limits for the transport and as well for the info about security and the referrer header.

    I’ve tried to tinker with as little as possible to make it not dependent on dojo (only because the project I’m trying to integrate it with is already written in jQuery). Everything seems to work ok, except the browser never stops loading after a request; ie, it completes a successful xd fetch of data but then continues to display “Transferring…” or “Loading…” indefinitely. I see the comment about having to write to and close the innerDoc in FF, but I’m seeing this problem in all browsers. Any ideas? I thought perhaps you might have encountered this problem when you were developing it. The only change I really had to make was to get rid of the use of _iosetArg and the deferred object. Would this affect it?



  • @Neil: I am not sure, I was able to fix the “Loading” by calling document.close() for the document (innerDoc). You might also want to take a look at the jQuery port of this module:

  • Ed

    So I’m getting the data in the auth window, but how do I store the data into a variable?


  • You should be able to get the data in the argument in deferred callback (and set it to a variable).

  • Chuck

    Ok I tried this and only got 1/2 working. I was able to call to diff site and got information I wanted and I know it is on the page, I used firebug, but I can’t get to the info with dojo.query it look like I’m block from accessing it on my own page. Any idea/solution? This is insane and really need help someone.