Protected Cross-Domain Access with Dojo’s windowName

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:

<div id="authTarget" style="width:400px; height:200px"></div>

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:

    <script type="text/javascript">
    function authorized(){
      // this the function that is called once authorization has been done,
      // you can use any type of authorization
      var loc =; = "My Data";
      location = loc;
    <button onclick="authorized()">Authorize this resource</button>

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:

<div id="authTarget" style="display:none; width:400px; height:200px">

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.

Learn more about how SitePen can be your partner.

SitePen is a strategic consultancy committed to achieving technical objectives, solving critical business problems and helping our customers build web applications the right way, the first time.
Share This