Fast forward 2015 and we try not to modify master pages following Microsoft guidance to be stay “cloud compatible” for future upgrades - which is a good thing btw.
<RANT ALERT> And this is why I really really dislike host named site collections. CORS and preview issues arise all the friggin time, and if you could just keep everything at https://intranet/path/ the consultancy cost would go down for you as a customer. It’s true! And I would rather you spend your money for me to do innovation on usage and adoption instead of jumping though technical hoops. </RANT ALERT>
To remedy this particular issue where you for some reason opted in to do host named site collections or web apps with
- intranet.company.com
- search.company.com
- collaboration.company.com
- etc.
By deploying this WSP with a simple delegate control, all your pages can be IFRAME’d where ever you want. Yes, there is the issue of click jacking, but since we’re on the intranet here I choose to disregard it and hope the compliance officer is ok with it (which he has to be if you manually add the AllowFraming component anyways right?)
And the beauty by using a farm solution with a farm scoped feature, it will be deployed automatically to any new front-end server you decide to add to your farm. It’s so awesome I’ll grant myself an extra cup of coffee!! And if you only want it on certain web apps and not the whole farm, grab the code and change the feature scope. So damn simple!
The code will per page inject the AllowFraming component into every page, making sure the X-Frame-Options header is removed from the HTTP responses. Just like it would if you modified the master page.
using System.Web.UI.WebControls; using Microsoft.SharePoint.WebControls; namespace mAdcOW.AllowFraming { [MdsCompliant(true)] public class InjectAllowFramingControl : WebControl { protected override void CreateChildControls() { Microsoft.SharePoint.WebPartPages.AllowFraming allowFraming = new Microsoft.SharePoint.WebPartPages.AllowFraming(); this.Controls.Add(allowFraming); } } }