Export (0) Print
Expand All

Addressing same-origin policy limitations in apps for Office

apps for Office

This article 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: May 01, 2015

Applies to: Access apps for SharePoint | apps for Office | Excel | Office Add-ins | Outlook | PowerPoint | Project | Word

Learn more about supported hosts and other requirements.

Note Note

The name "apps for Office" is changing to "Office Add-ins". During the transition, the documentation and the UI of some Office host applications and Visual Studio tools might still use the term "apps for Office".

In this article
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
Additional resources

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.

To overcome same-origin policy enforcement when you develop apps, you can:

  • 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:
© 2015 Microsoft