SharePoint 2013 – Integration Challenges with remote applications – #1 IFRAMES


I’m currently involved in integrating SharePoint with IBM Connections and I’m having a lot of fun trying to figure out all the possibilities. Since these integration considerations are not specific to SharePoint/IBM Connections, I’ll blog a series of posts which will be rather short or rather long according to the topic I’m focusing on.

In this post, I’m going to focus on a simple (or supposed to be) integration technique using IFRAMES.

One way to integrate SharePoint content/pages into another application is to declare an IFRAME in the remote application whose the source attribute targets the SharePoint page.

This is indeed true but you should know that, out of the box, SharePoint will add a X-Frame-Options response header with the value SAMEORIGIN which prevents integrating any SharePoint page into a remote application :).

So, if you wish to continue using IFRAMES, you’ll need to work around that issue by using one of the following methods:

  • Change the header from SAMEORIGIN to ALLOW-FROM in order to allow the remote domain, beware that this is not supported by all the browsers
  • Remove the header completely
  • Add a <WebPartPages:AllowFraming runat=”server” /> to your master page but keep in mind that it only works for ASPX pages. Moreover, depending on where you place the pages to integrate, you might need to update multiple master pages (if you system master page is # than the custom master page)

If you want to remove the header completely, you can develop an HTTP Module that checks the origin of the requestor and removes the X-Frame-Options from the response. The bottom line is the performance overhead since your module will be launched for every request on that particular web app including the out of the box pages etc…Moreover, if you apply Microsoft recommendations and use Host Named Site Collections, then your module will really be launched for every request since all your sites will live within the same webapp …:)

However, a HTTP Handler which would have been less invasive than an HTTP module is not an option in this case since the X-Frame-Options header is not present yet.

So, the less invasive option is to use .aspx pages with a minimal masterpage (remember that these pages are iframed so only the content should be shown) and add either in the page, either in a custom minimal masterpage the AllowFraming…but this only works for aspx pages so if you intended to IFRAME HTML pages, it’s not going to work.

In summary, the approach that’s working in every situation is the HTTP module but it’s also the most invasive while using the masterpage/page approach only works with aspx pages.

Happy Coding!

About Stephane Eyskens

Office 365, Azure PaaS and SharePoint platform expert
This entry was posted in Javascript and tagged , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s