iFrame support in SharePoint 2013

Recently I worked on a support case related to iFrame and SharePoint 2013.  What I learnt was an eye opener so I wanted to share this with the developer community just in case it helps.

Long story short, SharePoint does not support iFraming of editable pages in cross-domain scenario.  If you are developing something where you would be opening up an editable page (e.g., new/edit forms) within an iFrame, you will end up with a JavaScript access denied error.  Here’s some more details on this with steps to reproduce/test.

Consider you have a simple HTML page in an IIS web site (let’s say http://htm.contoso.com/test.htm) that has an iFrame.  This iFrame displays a SharePoint list form (e.g., http://dev.contoso.com/Lists/WFList2013/AllItems.aspx).  When you browse to the HTML page, the list form will render fine.  But when you click some option which involves associated JavaScript files (e.g., clicking the Edit Properties for a List Item ribbon action), it will throw a JavaScript error similar to what’s shown below and the form will not be loaded.

Webpage error details
User Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; .NET4.0E; MS-RTC LM 8; InfoPath.3)
Timestamp: Fri, 27 Jun 2014 11:27:43 UTC
Message: Access is denied.
Line: 1
Char: 60838
Code: 0
URI: http://dev.contoso.com/_layouts/15/init.js?rev=ZCyl%2Bj%2B4NZLoeodWTEXQ0Q%3D%3D
Message: Permission denied
Line: 1
Char: 106124
Code: 0
URI: http://dev.contoso.com/_layouts/15/init.js?rev=ZCyl%2Bj%2B4NZLoeodWTEXQ0Q%3D%3D

NOTE: This problem only happens in cross-domain scenario as shown above.

The JavaScript error and the call stack will look like the below:

"Error: Access is denied.\r\n\n   
at STSNavigate (http://dev.contoso.com/_layouts/15/init.js?rev=rQHvYUfURJXLBpgKnm0dcA%3D%3D:1:61098)\n   
at GoToPage (http://dev.contoso.com/_layouts/15/init.js?rev=rQHvYUfURJXLBpgKnm0dcA%3D%3D:1:61597)\n   
at _EditItem (http://dev.contoso.com/_layouts/15/core.js?rev=uA2xjCXmuYM5ARP8g3eTSA%3D%3D:1:80530)\n   
at _EditItem2 (http://dev.contoso.com/_layouts/15/core.js?rev=uA2xjCXmuYM5ARP8g3eTSA%3D%3D:1:80482)\n   
at b (http://dev.contoso.com/_layouts/15/init.js?rev=rQHvYUfURJXLBpgKnm0dcA%3D%3D:1:117426)\n   
at EnsureScript (http://dev.contoso.com/_layouts/15/init.js?rev=rQHvYUfURJXLBpgKnm0dcA%3D%3D:1:77871)\n   
at CoreInvoke (http://dev.contoso.com/_layouts/15/init.js?rev=rQHvYUfURJXLBpgKnm0dcA%3D%3D:1:117443)\n   
at EditItem2 (http://dev.contoso.com/_layouts/15/init.js?rev=rQHvYUfURJXLBpgKnm0dcA%3D%3D:1:138408)\n   
at eval code (eval code:1:76)\n   
at SP.Ribbon.NativeUtility.executeECBCommand (http://dev.contoso.com/_layouts/15/sp.ribbon.js?rev=d4Y4E0ghdo65Uz4tti0FZw%3D%3D:2:222153)"

This is an intentional security measure put in place to mitigate clickjacking vulnerability and it is documented in IFraming SharePoint-hosted pages in apps.

Just wanted to call this out explicitly in the hope that this information helps you in better designing and architecting your SharePoint 2013 solutions.

Comments (1)

Skip to main content