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 https://htm.contoso.com/test.htm) that has an iFrame. This iFrame displays a SharePoint list form (e.g., https://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: https://dev.contoso.com/_layouts/15/init.js?rev=ZCyl%2Bj%2B4NZLoeodWTEXQ0Q%3D%3D
Message: Permission denied
Line: 1
Char: 106124
Code: 0
URI: https://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:
stack:
"Error: Access is denied.\r\n\n
at STSNavigate (https://dev.contoso.com/_layouts/15/init.js?rev=rQHvYUfURJXLBpgKnm0dcA%3D%3D:1:61098)\n
at GoToPage (https://dev.contoso.com/_layouts/15/init.js?rev=rQHvYUfURJXLBpgKnm0dcA%3D%3D:1:61597)\n
at _EditItem (https://dev.contoso.com/_layouts/15/core.js?rev=uA2xjCXmuYM5ARP8g3eTSA%3D%3D:1:80530)\n
at _EditItem2 (https://dev.contoso.com/_layouts/15/core.js?rev=uA2xjCXmuYM5ARP8g3eTSA%3D%3D:1:80482)\n
at b (https://dev.contoso.com/_layouts/15/init.js?rev=rQHvYUfURJXLBpgKnm0dcA%3D%3D:1:117426)\n
at EnsureScript (https://dev.contoso.com/_layouts/15/init.js?rev=rQHvYUfURJXLBpgKnm0dcA%3D%3D:1:77871)\n
at CoreInvoke (https://dev.contoso.com/_layouts/15/init.js?rev=rQHvYUfURJXLBpgKnm0dcA%3D%3D:1:117443)\n
at EditItem2 (https://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 (https://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
- Anonymous
October 04, 2014
thank you for sharing