Quantcast
Channel: ventigrate Wiki Rss Feed
Viewing all 51 articles
Browse latest View live

Updated Wiki: Win Auto SignIn

$
0
0

Win Auto SignIn

Claims based authentication in SharePoint 2010 and SharePoint 2013 works with a FedAuth token that can be kept on the local machine for a configurable amount of time. This leads to an effective Single Sign On even between client reboots, as long as the cookie and the token aren't expired yet. The SSO experience also works for Microsoft Office and Explorer View, so the user can transparently open and edit documents and workbooks from the SharePoint environment.

When configuring the Web Application with only Windows Authentication, the FedAuth cookie isn't written and the Windows handshake will need to redone when the browser is closed or when opening documents from Office applications. If the client cannot automatically authenticate the Windows user, it will present a credential prompt which may be undesired.

The Win Auto SignIn component is a sign in page for a Claims Authentication Web Application that automatically redirects all requests to do Windows (NTLM, Kerberos, BASIC) sign in for SharePoint 2010 and SharePoint 2013. It has the benefit that it will generate a FedAuth cookie for the Windows user as well.

Installation

Add and deploy the SharePoint Solution Package (.wsp) using PowerShell:

Add-PSSnapin "Microsoft.SharePoint.PowerShell" -ErrorAction SilentlyContinue
Add-SPSolution Ventigrate.Shared.WinAutoSignIn.wsp -ErrorAction SilentlyContinue
Install-SPSolution Ventigrate.Shared.WinAutoSignIn.wsp -GACDeployment -Force

Configuration

Configure the Authentication for you SharePoint Web Application to use the custom sign in page. You need to enable Windows Authentication (because that will be the single authentication used by users) and Forms Based Authentication as well. You can provide a dummy value for the Membership Provider since we won't be using it. You need to check FBA because otherwise the custom login page will just be ignored.

<foto>

Use

Once you have the dual authentication (Windows and FBA) and custom sign in page configured, your users will automatically be redirected to use Windows authentication for the SharePoint Web Application, but with the benefit of having a FedAuth cookie.

Cookie and Token Lifetime

Cookie and token lifetime can be configured for the SharePoint Security Token Service using PowerShell:

$sts = Get-SPSecurityTokenServiceConfig
$sts.WindowsTokenLifeTime = (New-TimeSpan -Days 1)
$sts.Update()
iisreset

Updated Wiki: Temporary Post Used For Theme Detection (3a219923-20c3-4873-b543-086978d353cb - 3bfe001a-32de-4114-a6b4-4005b770f6d7)

$
0
0

This is a temporary post that was not deleted. Please delete this manually. (f944ced5-2b62-4596-9a90-0dcdfc764706 - 3bfe001a-32de-4114-a6b4-4005b770f6d7)

Updated Wiki: Win Auto SignIn

$
0
0

Win Auto SignIn

Claims based authentication in SharePoint 2010 and SharePoint 2013 works with a FedAuth token that can be kept on the local machine for a configurable amount of time. This leads to an effective Single Sign On even between client reboots, as long as the cookie and the token aren't expired yet. The SSO experience also works for Microsoft Office and Explorer View, so the user can transparently open and edit documents and workbooks from the SharePoint environment.

When configuring the Web Application with only Windows Authentication, the FedAuth cookie isn't written and the Windows handshake will need to redone when the browser is closed or when opening documents from Office applications. If the client cannot automatically authenticate the Windows user, it will present a credential prompt which may be undesired.

The Win Auto SignIn component is a sign in page for a Claims Authentication Web Application that automatically redirects all requests to do Windows (NTLM, Kerberos, BASIC) sign in for SharePoint 2010 and SharePoint 2013. It has the benefit that it will generate a FedAuth cookie for the Windows user as well.

Installation

Add and deploy the SharePoint Solution Package (.wsp) using PowerShell:

Add-PSSnapin "Microsoft.SharePoint.PowerShell" -ErrorAction SilentlyContinue
Add-SPSolution Ventigrate.Shared.WinAutoSignIn.wsp -ErrorAction SilentlyContinue
Install-SPSolution Ventigrate.Shared.WinAutoSignIn.wsp -GACDeployment -Force

Configuration

Configure the Authentication for you SharePoint Web Application to use the custom sign in page. You need to enable Windows Authentication (because that will be the single authentication used by users) and Forms Based Authentication as well. You can provide a dummy value for the Membership Provider since we won't be using it. You need to check FBA because otherwise the custom login page will just be ignored.

Web Application Authentication Settings

Use

Once you have the dual authentication (Windows and FBA) and custom sign in page configured, your users will automatically be redirected to use Windows authentication for the SharePoint Web Application, but with the benefit of having a FedAuth cookie.

Cookie and Token Lifetime

Cookie and token lifetime can be configured for the SharePoint Security Token Service using PowerShell:

$sts = Get-SPSecurityTokenServiceConfig
$sts.WindowsTokenLifeTime = (New-TimeSpan -Days 1)
$sts.Update()
iisreset

Updated Wiki: Home

$
0
0
Project Description
This repository contains solutions and techniques that were developed by employees of Ventigrate and that are shared for the benefit of the community.


Projects and Samples:

* Win Auto SignIn (13 May 2013)
* External User Management (SharePoint 2010 and SharePoint 2013) (22 February 2013)
* Advanced Computed Field (1 March 2012)
* Delete All Items Ribbon Button (8 Feb 2012)
* Permissive XFrame Header (3 Jan 2012)
* Anonymous Version History (3 Jan 2012)
* Sandboxed Logging (26 Dec 2011)
* MUI Search Refinement Panel (13 Dec 2011)
* User Profile Exclusion Filters (20 Jul 2011)
* Taxonomy Uploader (1 Jun 2011)

Updated Wiki: Home

$
0
0
Project Description
This repository contains solutions and techniques that were developed by employees of Ventigrate and that are shared for the benefit of the community.


Projects and Samples:

* Win Auto SignIn (13 May 2013)
* External User Management (SharePoint 2010 and SharePoint 2013) (22 February 2013)
* Advanced Computed Field (1 March 2012)
* Delete All Items Ribbon Button (8 Feb 2012)
* Permissive XFrame Header (3 Jan 2012)
* Anonymous Version History (3 Jan 2012)
* Sandboxed Logging (26 Dec 2011)
* MUI Search Refinement Panel (13 Dec 2011)
* User Profile Exclusion Filters (20 Jul 2011)
* Taxonomy Uploader (1 Jun 2011)

Updated Wiki: Home

$
0
0
Project Description
This repository contains solutions and techniques that were developed by employees of Ventigrate and that are shared for the benefit of the community.


Projects and Samples:

* Advanced Computed Field (SharePoint 2010 and SharePoint 2013) (9 May 2014)
* Win Auto SignIn (13 May 2013)
* External User Management (SharePoint 2010 and SharePoint 2013) (22 February 2013)
* Delete All Items Ribbon Button (8 Feb 2012)
* Permissive XFrame Header (3 Jan 2012)
* Anonymous Version History (3 Jan 2012)
* Sandboxed Logging (26 Dec 2011)
* MUI Search Refinement Panel (13 Dec 2011)
* User Profile Exclusion Filters (20 Jul 2011)
* Taxonomy Uploader (1 Jun 2011)

Updated Wiki: Advanced Computed Field

$
0
0

Advanced Computed Field

The Advanced Computed Field is a Custom Field Type for SharePoint 2010 and SharePoint 2013 that allows powerful and rich visualisation of other metadata fields on a document or list item. It has two configuration options: one is to specify which field values you want it to include, the other one allows defining the HTML markup combined with the specified field values.

This field was originally created for SharePoint 2007 and can still be downloaded here: http://www.sharepointblogs.be/blogs/vandest/archive/2009/03/31/advanced-computed-field.aspx


Use it for:

  • Rich Text Formatting, Highlighting, ... of field values
  • Constructing parameterized URLs or mailto-links
  • Rendering of form controls (like a button) with javascript logic
  • Advanced javascript processing (create ellipsis of the 'Body' of an item)
  • ...

Other practical examples of use:

Installation

Add and deploy the SharePoint Solution Package (.wsp) using STSADM or PowerShell:

STSADM -o addsolution -filename VNTG.CustomFieldTypes.AdvancedComputedField.wsp 
STSADM -o deploysolution -name VNTG.CustomFieldTypes.AdvancedComputedField.wsp -allowgacdeployment -immediate -allcontenturls

Changelog

  • 1 March 2012: Added XSL template to fix an issue with Connected Web Parts not showing value for the Advanced Computed Fields (thanks Federico Sanchez !)
  • 9 May 2014: Created a SharePoint 2013 version of the Advanced Computed Field

Updated Wiki: Advanced Computed Field

$
0
0

Advanced Computed Field

The Advanced Computed Field is a Custom Field Type for SharePoint 2010 and SharePoint 2013 that allows powerful and rich visualisation of other metadata fields on a document or list item. It has two configuration options: one is to specify which field values you want it to include, the other one allows defining the HTML markup combined with the specified field values.

This field was originally created for SharePoint 2007 and can still be downloaded here: http://www.sharepointblogs.be/blogs/vandest/archive/2009/03/31/advanced-computed-field.aspx


Use it for:

  • Rich Text Formatting, Highlighting, ... of field values
  • Constructing parameterized URLs or mailto-links
  • Rendering of form controls (like a button) with javascript logic
  • Advanced javascript processing (create ellipsis of the 'Body' of an item)
  • ...

Other practical examples of use:

Installation

Add and deploy the SharePoint Solution Package (.wsp) using STSADM or PowerShell:

STSADM -o addsolution -filename VNTG.CustomFieldTypes.AdvancedComputedField.wsp 
STSADM -o deploysolution -name VNTG.CustomFieldTypes.AdvancedComputedField.wsp -allowgacdeployment -immediate -allcontenturls

Changelog

  • 1 March 2012: Added XSL template to fix an issue with Connected Web Parts not showing value for the Advanced Computed Fields (thanks Federico Sanchez !)
  • 9 May 2014: Created a SharePoint 2013 version of the Advanced Computed Field
  • 28 May 2014: Bugfix in "Edit Field" for SharePoint 2013 version of the Advanced Computed Field

Updated Wiki: Home

$
0
0
Project Description
This repository contains solutions and techniques that were developed by employees of Ventigrate and that are shared for the benefit of the community.


Projects and Samples:

* Advanced Computed Field (SharePoint 2010 and SharePoint 2013) (28 May 2014)
* Win Auto SignIn (13 May 2013)
* External User Management (SharePoint 2010 and SharePoint 2013) (22 February 2013)
* Delete All Items Ribbon Button (8 Feb 2012)
* Permissive XFrame Header (3 Jan 2012)
* Anonymous Version History (3 Jan 2012)
* Sandboxed Logging (26 Dec 2011)
* MUI Search Refinement Panel (13 Dec 2011)
* User Profile Exclusion Filters (20 Jul 2011)
* Taxonomy Uploader (1 Jun 2011)

Updated Wiki: Permissive XFrame Header

$
0
0

Permissive XFrame Header

A SharePoint 2010 and SharePoint 2013 module that will allow SharePoint, Excel Services, Office Web Apps or InfoPath Forms Services to be rendered inside cross-domain iframes.

 

Consider a scenario where you want to display a with Excel Services rendered workbook inside a cross-domain iframe:

But because Excel Services and Office Web Apps render a HTTP response header X-FRAME-OPTIONS: SAMEORIGIN this won’t work and you get“This content cannot be displayed in a frame”

The content cannot be displayed in a frame

Not used to seeing such a straight-forward error :)

I did a bit of investigating but couldn’t find an easy way to configure this through UI or Powershell, so I was left with the following options:

  • Strip the header in a reverse proxy (between client and SharePoint server) like Apache or ForeFront
  • Remove the header with development of a HttpModule

PermissiveXFrameHeader

I wrote up a quick HttpModule that can be activated by Web Application Feature and will remove the X-FRAME-OPTIONS header no questions asked.

[31/10/2014]: Updated to work with InfoPath Forms Services as well.

Installation and activation

Download from here (Ventigrate Codeplex Repository)

Deploy the WSP (farm solution) to the SharePoint Farm

Add-SPSolution C:\temp\Ventigrate.Shared.PermissiveXFrameHeader.wsp
Install-SPSolution Ventigrate.Shared.PermissiveXFrameHeader.wsp -GACDeploy

Activate the Web Application Feature to the Web Application referred to in the iframe

Manage Web Application Features

Final note

The header was designed to protect against clickjacking. If you intend to use the above solution keep this in mind and plan for it accordingly.

Original blog

http://www.sharepointblogs.be/blogs/vandest/archive/2012/01/03/sharepoint-2010-office-web-apps-and-iframes.aspx

Updated Wiki: Home

$
0
0
Project Description
This repository contains solutions and techniques that were developed by employees of Ventigrate and that are shared for the benefit of the community.


Projects and Samples:

* Permissive XFrame Header (SharePoint 2010 and SharePoint 2013) (31 Oct 2014)
* Advanced Computed Field (SharePoint 2010 and SharePoint 2013) (28 May 2014)
* Win Auto SignIn (13 May 2013)
* External User Management (SharePoint 2010 and SharePoint 2013) (22 February 2013)
* Delete All Items Ribbon Button (8 Feb 2012)
* Anonymous Version History (3 Jan 2012)
* Sandboxed Logging (26 Dec 2011)
* MUI Search Refinement Panel (13 Dec 2011)
* User Profile Exclusion Filters (20 Jul 2011)
* Taxonomy Uploader (1 Jun 2011)

Updated Wiki: Permissive XFrame Header

$
0
0

Permissive XFrame Header

A SharePoint 2010 and SharePoint 2013 module that will allow SharePoint, Excel Services, Office Web Apps or InfoPath Forms Services to be rendered inside cross-domain iframes.

This post is an update/extension to an older one (“SharePoint 2010: Office Web Apps and iframes”) on rendering Excel Services in an iframe on a different domain. This is prohibited because a HTTP response headerX-FRAME-OPTIONS: SAMEORIGIN is added to the response. The solution presented there isn’t limited to Excel Services but is applicable to any SharePoint-hosted page that you want to visualize in an iframe.

Consider the following:

  • SharePoint 2013 will always render the X-FRAME-OPTIONS header, even for regular pages. Adding anAllowFraming control to the page fixes that, but doesn’t cover all situations
  • You can’t add the AllowFraming control to Office Web Apps or InfoPath Forms Server (“FormServer.aspx”)
  • Clicking on (pdf) documents in a Document Library in the iframe will fail to load them because the document is a different request
  • You have a basic “integration” between different systems (like Dynamics CRM) and SharePoint content that uses iframes

The content cannot be displayed in a frame

PermissiveXFrameHeader

This is a HttpModule that can be activated per Web Application by Web Application Feature and will ensure that all pages will render inside an iframe. While the initial version would actually remove the offending response header, the module will now set values that will prevent SharePoint from trying to inject the header in the first place.

Installation and activation

Download from here (Ventigrate Codeplex Repository)

Deploy the WSP (farm solution) to the SharePoint Farm

Activate the Web Application Feature to the Web Application referred to in the iframe

 

 

References

http://www.sharepointblogs.be/blogs/vandest/archive/2012/01/03/sharepoint-2010-office-web-apps-and-iframes.aspx

 

Updated Wiki: Permissive XFrame Header

$
0
0

Permissive XFrame Header

A SharePoint 2010 and SharePoint 2013 module that will allow SharePoint, Excel Services, Office Web Apps or InfoPath Forms Services to be rendered inside cross-domain iframes.

This post is an update/extension to an older one (“SharePoint 2010: Office Web Apps and iframes”) on rendering Excel Services in an iframe on a different domain. This is prohibited because a HTTP response headerX-FRAME-OPTIONS: SAMEORIGIN is added to the response. The solution presented there isn’t limited to Excel Services but is applicable to any SharePoint-hosted page that you want to visualize in an iframe.

Consider the following:

  • SharePoint 2013 will always render the X-FRAME-OPTIONS header, even for regular pages. Adding anAllowFraming control to the page fixes that, but doesn’t cover all situations
  • You can’t add the AllowFraming control to Office Web Apps or InfoPath Forms Server (“FormServer.aspx”)
  • Clicking on (pdf) documents in a Document Library in the iframe will fail to load them because the document is a different request
  • You have a basic “integration” between different systems (like Dynamics CRM) and SharePoint content that uses iframes

The content cannot be displayed in a frame

PermissiveXFrameHeader

This is a HttpModule that can be activated per Web Application by Web Application Feature and will ensure that all pages will render inside an iframe. While the initial version would actually remove the offending response header, the module will now set values that will prevent SharePoint from trying to inject the header in the first place.

Installation and activation

Download from here (Ventigrate Codeplex Repository)

Deploy the WSP (farm solution) to the SharePoint Farm

Activate the Web Application Feature to the Web Application referred to in the iframe

 

 

References

http://www.sharepointblogs.be/blogs/vandest/archive/2012/01/03/sharepoint-2010-office-web-apps-and-iframes.aspx

 

Updated Wiki: Permissive XFrame Header

$
0
0

Permissive XFrame Header

A SharePoint 2010 and SharePoint 2013 module that will allow SharePoint, Excel Services, Office Web Apps or InfoPath Forms Services to be rendered inside cross-domain iframes.

This post is an update/extension to an older one (“SharePoint 2010: Office Web Apps and iframes”) on rendering Excel Services in an iframe on a different domain. This is prohibited because a HTTP response headerX-FRAME-OPTIONS: SAMEORIGIN is added to the response. The solution presented there isn’t limited to Excel Services but is applicable to any SharePoint-hosted page that you want to visualize in an iframe.

Consider the following:

  • SharePoint 2013 will always render the X-FRAME-OPTIONS header, even for regular pages. Adding anAllowFraming control to the page fixes that, but doesn’t cover all situations
  • You can’t add the AllowFraming control to Office Web Apps or InfoPath Forms Server (“FormServer.aspx”)
  • Clicking on (pdf) documents in a Document Library in the iframe will fail to load them because the document is a different request
  • You have a basic “integration” between different systems (like Dynamics CRM) and SharePoint content that uses iframes

The content cannot be displayed in a frame

PermissiveXFrameHeader

This is a HttpModule that can be activated per Web Application by Web Application Feature and will ensure that all pages will render inside an iframe. While the initial version would actually remove the offending response header, the module will now set values that will prevent SharePoint from trying to inject the header in the first place.

Installation and activation

Download from here (Ventigrate Codeplex Repository)

Deploy the WSP (farm solution) to the SharePoint Farm

Activate the Web Application Feature for the Web Application you want to host inside an iframe

References

http://www.sharepointblogs.be/blogs/vandest/archive/2012/01/03/sharepoint-2010-office-web-apps-and-iframes.aspx

 

Updated Wiki: Permissive XFrame Header

$
0
0

Permissive XFrame Header

A SharePoint 2010 and SharePoint 2013 module that will allow SharePoint, Excel Services, Office Web Apps or InfoPath Forms Services to be rendered inside cross-domain iframes.

This post is an update/extension to an older one (“SharePoint 2010: Office Web Apps and iframes”) on rendering Excel Services in an iframe on a different domain. This is prohibited because a HTTP response headerX-FRAME-OPTIONS: SAMEORIGIN is added to the response. The solution presented there isn’t limited to Excel Services but is applicable to any SharePoint-hosted page that you want to visualize in an iframe.

Consider the following:

  • SharePoint 2013 will always render the X-FRAME-OPTIONS header, even for regular pages. Adding anAllowFraming control to the page fixes that, but doesn’t cover all situations
  • You can’t add the AllowFraming control to Office Web Apps or InfoPath Forms Server (“FormServer.aspx”)
  • Clicking on (pdf) documents in a Document Library in the iframe will fail to load them because the document is a different request
  • You have a basic “integration” between different systems (like Dynamics CRM) and SharePoint content that uses iframes

The content cannot be displayed in a frame

PermissiveXFrameHeader

This is a HttpModule that can be activated per Web Application by Web Application Feature and will ensure that all pages will render inside an iframe. While the initial version would actually remove the offending response header, the module will now set values that will prevent SharePoint from trying to inject the header in the first place.

Installation and activation

Download from here (Ventigrate Codeplex Repository)

Deploy the WSP (farm solution) to the SharePoint Farm

Activate the Web Application Feature for the Web Application you want to host inside an iframe

References

http://www.moss2007.be/blogs/vandest/archive/2012/01/03/sharepoint-2010-office-web-apps-and-iframes.aspx

 


Updated Wiki: Permissive XFrame Header

$
0
0

Permissive XFrame Header

A SharePoint 2010 and SharePoint 2013 module that will allow SharePoint, Excel Services, Office Web Apps or InfoPath Forms Services to be rendered inside cross-domain iframes.

This post is an update/extension to an older one (“SharePoint 2010: Office Web Apps and iframes”) on rendering Excel Services in an iframe on a different domain. This is prohibited because a HTTP response headerX-FRAME-OPTIONS: SAMEORIGIN is added to the response. The solution presented there isn’t limited to Excel Services but is applicable to any SharePoint-hosted page that you want to visualize in an iframe.

Consider the following:

  • SharePoint 2013 will always render the X-FRAME-OPTIONS header, even for regular pages. Adding anAllowFraming control to the page fixes that, but doesn’t cover all situations
  • You can’t add the AllowFraming control to Office Web Apps or InfoPath Forms Server (“FormServer.aspx”)
  • Clicking on (pdf) documents in a Document Library in the iframe will fail to load them because the document is a different request
  • You have a basic “integration” between different systems (like Dynamics CRM) and SharePoint content that uses iframes

The content cannot be displayed in a frame

PermissiveXFrameHeader

This is a HttpModule that can be activated per Web Application by Web Application Feature and will ensure that all pages will render inside an iframe. While the initial version would actually remove the offending response header, the module will now set values that will prevent SharePoint from trying to inject the header in the first place.

Installation and activation

Download from here (Ventigrate Codeplex Repository)

Deploy the WSP (farm solution) to the SharePoint Farm

Activate the Web Application Feature for the Web Application you want to host inside an iframe

References

http://www.sharepointblogs.be/blogs/vandest/archive/2012/01/03/sharepoint-2010-office-web-apps-and-iframes.aspx

 

Updated Wiki: Permissive XFrame Header

$
0
0

Permissive XFrame Header

A SharePoint 2010 and SharePoint 2013 module that will allow SharePoint, Excel Services, Office Web Apps or InfoPath Forms Services to be rendered inside cross-domain iframes.

This post is an update/extension to an older one (“SharePoint 2010: Office Web Apps and iframes”) on rendering Excel Services in an iframe on a different domain. This is prohibited because a HTTP response headerX-FRAME-OPTIONS: SAMEORIGIN is added to the response. The solution presented there isn’t limited to Excel Services but is applicable to any SharePoint-hosted page that you want to visualize in an iframe.

Consider the following:

  • SharePoint 2013 will always render the X-FRAME-OPTIONS header, even for regular pages. Adding anAllowFraming control to the page fixes that, but doesn’t cover all situations
  • You can’t add the AllowFraming control to Office Web Apps or InfoPath Forms Server (“FormServer.aspx”)
  • Clicking on (pdf) documents in a Document Library in the iframe will fail to load them because the document is a different request
  • You have a basic “integration” between different systems (like Dynamics CRM) and SharePoint content that uses iframes

The content cannot be displayed in a frame

PermissiveXFrameHeader

This is a HttpModule that can be activated per Web Application by Web Application Feature and will ensure that all pages will render inside an iframe. While the initial version would actually remove the offending response header, the module will now set values that will prevent SharePoint from trying to inject the header in the first place.

Installation and activation

Download from here (Ventigrate Codeplex Repository)

Deploy the WSP (farm solution) to the SharePoint Farm

Activate the Web Application Feature for the Web Application you want to host inside an iframe

References

http://www.sharepointblogs.be/blogs/vandest/archive/2012/01/03/sharepoint-2010-office-web-apps-and-iframes.aspx

Updated Wiki: Permissive XFrame Header

$
0
0

Permissive XFrame Header

A SharePoint 2010 and SharePoint 2013 module that will allow SharePoint, Excel Services, Office Web Apps or InfoPath Forms Services to be rendered inside cross-domain iframes.

This post is an update/extension to an older one (“SharePoint 2010: Office Web Apps and iframes”) on rendering Excel Services in an iframe on a different domain. This is prohibited because a HTTP response headerX-FRAME-OPTIONS: SAMEORIGIN is added to the response. The solution presented there isn’t limited to Excel Services but is applicable to any SharePoint-hosted page that you want to visualize in an iframe.

Consider the following:

  • SharePoint 2013 will always render the X-FRAME-OPTIONS header, even for regular pages. Adding anAllowFraming control to the page fixes that, but doesn’t cover all situations
  • You can’t add the AllowFraming control to Office Web Apps or InfoPath Forms Server (“FormServer.aspx”)
  • Clicking on (pdf) documents in a Document Library in the iframe will fail to load them because the document is a different request
  • You have a basic “integration” between different systems (like Dynamics CRM) and SharePoint content that uses iframes

The content cannot be displayed in a frame

PermissiveXFrameHeader

This is a HttpModule that can be activated per Web Application by Web Application Feature and will ensure that all pages will render inside an iframe. While the initial version would actually remove the offending response header, the module will now set values that will prevent SharePoint from trying to inject the header in the first place.

Installation and activation

Download from here (Ventigrate Codeplex Repository)

Deploy the WSP (farm solution) to the SharePoint Farm

Activate the Web Application Feature for the Web Application you want to host inside an iframe

References

http://www.sharepointblogs.be/blogs/vandest/archive/2012/01/03/sharepoint-2010-office-web-apps-and-iframes.aspx

Updated Wiki: Home

$
0
0
Project Description
This repository contains solutions and techniques that were developed by employees of Ventigrate and that are shared for the benefit of the community.


Projects and Samples:

* Permissive XFrame Header (SharePoint 2010 and SharePoint 2013) (31 Oct 2014)
* Advanced Computed Field (SharePoint 2010 and SharePoint 2013) (28 May 2014)
* Win Auto SignIn (SharePoint 2010 and SharePoint 2013) (13 May 2013)
* External User Management (SharePoint 2010 and SharePoint 2013) (22 February 2013)
* Delete All Items Ribbon Button (8 Feb 2012)
* Anonymous Version History (3 Jan 2012)
* Sandboxed Logging (26 Dec 2011)
* MUI Search Refinement Panel (13 Dec 2011)
* User Profile Exclusion Filters (20 Jul 2011)
* Taxonomy Uploader (1 Jun 2011)

Updated Wiki: Permissive XFrame Header

$
0
0

Permissive XFrame Header

A SharePoint 2010 and SharePoint 2013 module that will allow SharePoint, Excel Services, Office Web Apps or InfoPath Forms Services to be rendered inside cross-domain iframes.

This post is a revision of an old blog post on rendering Excel Services in an iframe on a different domain. This is prohibited because a HTTP response headerX-FRAME-OPTIONS: SAMEORIGIN is added to the response. The issue isn’t limited to Excel Services but is applicable to any SharePoint-hosted page that you want to visualize in an iframe.

Consider the following:

  • SharePoint 2013 will always render the X-FRAME-OPTIONS header, even for regular pages. Adding anAllowFraming control to the page fixes that, but doesn’t cover all situations
  • You can’t add the AllowFraming control to Office Web Apps or InfoPath Forms Server (“FormServer.aspx”)
  • Clicking on (pdf) documents in a Document Library in the iframe will fail to load them because the document is a different request
  • You have a basic “integration” between different systems (like Dynamics CRM) and SharePoint content that uses iframes

The content cannot be displayed in a frame

PermissiveXFrameHeader

This is a HttpModule that can be activated per Web Application by Web Application Feature and will ensure that all pages will render inside an iframe. While the initial version would actually remove the offending response header, the module will now set values that will prevent SharePoint from trying to inject the header in the first place.

Installation and activation

Download from here (Ventigrate Codeplex Repository)

Deploy the WSP (farm solution) to the SharePoint Farm

Activate the Web Application Feature for the Web Application you want to host inside an iframe

References

http://www.sharepointblogs.be/blogs/vandest/archive/2012/01/03/sharepoint-2010-office-web-apps-and-iframes.aspx

Viewing all 51 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>