Export (0) Print
Expand All

Addressing same-origin policy limitations in apps for Office

apps for Office

This topic provides a brief overview of ways to address the same-origin policy limitations that prevent a script loaded from one domain from getting or manipulating properties of a document from another domain in an app for Office.

Last modified: February 27, 2014

Applies to: Access app for SharePoint | Excel 2013 | Excel 2013 RT | Excel 2013 SP1 | Excel Online | Outlook 2013 | Outlook 2013 RT | Outlook 2013 SP1 | Outlook Web App | OWA for Devices | PowerPoint 2013 | PowerPoint 2013 RT | PowerPoint 2013 SP1 | PowerPoint Online | Project 2013 | Project 2013 SP1 | Word 2013 | Word 2013 RT | Word 2013 SP1

   Office.js: v1.0, v1.1

In this article
Overview of same-origin policy enforcement
Using JSON/P for anonymous access
Implementing server-side script using a token-based authentication scheme
Using cross-origin resource sharing (CORS)
Building your own proxy using IFRAME and POST MESSAGE

The same-origin policy enforced by the browser prevents a script loaded from one domain from getting or manipulating properties of a webpage from another domain. This means that, by default, the domain of a requested URL must be the same as the domain of the current webpage. For example, this policy will prevent a webpage in one domain from making XmlHttpRequest web-service calls to a domain other than the one where it is hosted.

Because apps for Office are hosted in a browser control, the same-origin policy applies to script running in their web pages as well.

There are a number of ways of overcoming same-origin policy enforcement when you develop apps:

  • Use JSON/P for anonymous access

  • Implement server-side script using a token-based authentication scheme.

  • Using cross-origin resource sharing (CORS).

  • Build your own proxy using IFRAME and POST MESSAGE.

One way to overcome this limitation is to use JSON/P to provide a proxy for the web service. You do this by including a script tag with a src attribute that points to some script hosted on any domain. You can programmatically create the script tags, dynamically create the URL to point the src attribute to, and then pass parameters to the URL via URI query parameters. Web service providers create and host JavaScript code at specific URLs, and return different scripts depending on the URI query parameters. These scripts then execute where they are inserted and work as expected.

The following is an example of JSON/P from the mail app shown in Sample: Create a mail app to view YouTube videos in Outlook. However, this technique will work in any app for Office.

// Dynamically create an HTML SCRIPT element that obtains the details for the specified video.
function loadVideoDetails(videoIndex) {
    // Dynamically create a new HTML SCRIPT element in the webpage.
    var script = document.createElement("script");
    // Specify the URL to retrieve the indicated video from a feed of a current list of videos,
    // as the value of the src attribute of the SCRIPT element. 
    script.setAttribute("src", "https://gdata.youtube.com/feeds/api/videos/" + 
        videos[videoIndex].Id + "?alt=json-in-script&callback=videoDetailsLoaded");
    // Insert the SCRIPT element at the end of the HEAD section.
    document.getElementsByTagName('head')[0].appendChild(script);
}

Another way to address same-origin policy limitations is to implement the app's webpage as an ASP page that uses OAuth or caches credentials in cookies.

For an example that uses OAuth for authentication, see Twitter SharePoint web part with OAuth.

For an example of server-side code that shows how to use the Cookie object in System.Net to get and set cookie values, see the Value property.

For an example of using the cross-origin resource sharing feature of XmlHttpRequest2, see the "Cross Origin Resource Sharing (CORS)" section of New Tricks in XMLHttpRequest2.

For an example of how to build your own proxy using IFRAME and POST MESSAGE, see Cross-Window Messaging.

Show:
© 2014 Microsoft