0

So I have two SharePoint farms running like so:

app1.subdomain.domain.com (2013, source)

app2.subdomain.domain.com (2010, destination)

we have an iframe in app2 page pointing to a page in app1

after moving app1 to a different server farm, IE is complaining and refusing to display the iframe

if I add allowframing to the source farm it kinda works. in chrome its working 100%, in IE I get a lot of script errors and everything is broken in the frame.

<WebPartPages:AllowFraming runat="server" />

apparently I have to write an http module, but I was under the impression that this should only happen on different domains, and would like to clear that out.

2

From IEInternals blog:

If the value contains the token SAMEORIGIN, the browser will block rendering only if the origin of the top-level browsing-context is different than the origin of the content containing the X-FRAME-OPTIONS directive. For instance, if http://shop.example.com/confirm.asp contains the X-FRAME-OPTIONS directive with the SAMEORIGIN token, the page may be framed by any page from the exact http://shop.example.com origin.

...

Keep in mind that if a page specifies SAMEORIGIN, browsers will forbid framing only if the top-level origin FQDN (fully-qualified-domain-name, aka what you see in the address bar) does not exactly match FQDN of the subframe page that demanded the SAMEORIGIN restriction


So it seems app1.subdomain.domain.com and app2.subdomain.domain.com are considered different FQDNs. And I can the logic here - take O365 sites for example, a.sharepoint.com and b.sharepoint.com.

Try PermissiveXFrameHeader, module's author says "adding an AllowFraming control to the page fixes that, but doesn’t cover all situations".

  • +1 sounds about right. I'll see if there are any other approaches before I go ahead and accept it. deploying a wsp is not really what I was hoping, but if it comes to that, so be it – Tiago Duarte Mar 14 '16 at 15:39
  • Do you have Safari in reach? It seems that browser logs explicit "Protocols, domains, and ports must match" error in those scenarios. – Aziz Kabyshev Mar 14 '16 at 15:44
0

turns out I had actually not 1 but 2 problems:

  • X-Frame-Options is introduced in SharePoint 2013 by default and in order to work around it we either disable it globally (Permissive Header, etc.) or locally (AllowFraming control)
  • In a SP2010 site iframing a SP2013 site you will potentially have lots of script issues because after IE9 both pages (source and iframe) will display in the same IE Mode (e.g. 8)

For further reading, feel free to check my blog post on this.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.