January 26, 2012 - 13:09, by Steven Van de Craen
Categories: SOAP, SharePoint 2010
Today we were experimenting with SharePoint 2010 CSOM (Client Side Object Model) and we noticed strange errors such as HTTP ERROR 417 were returned. When browsing to Lists.asmx and Sites.asmx we got the following error:
The top XML element 'string' from namespace 'http://schemas.microsoft.com/sharepoint/soap/' references distinct types System.String and Microsoft.SharePoint.SoapServer.SoapXml.SoapXmlElement. Use XML attributes to specify another XML name or namespace for the element or types.
One of the MSDN Forums’ answers stated that you could use direct WSDL link (http://url/_vti_bin/sites.asmx?wsdl) and that would work, which it does in the browser but not for CSOM. And besides, I don’t like these kind of errors on one of my environments while other environments work fine.
Turned out someone had disabled HttpGet, HttpPost and HttpPostLocalhost protocols in the web.config of the ISAPI folder (maps to _vti_bin).
Uncomment those lines and your Web Services should be fine again.
January 5, 2012 - 11:22, by Steven Van de Craen
Categories: SharePoint 2010, Search
Posting this for personal reference:
SharePoint 2010 - Configuring Adobe PDF iFilter 9 for 64-bit platforms
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office Server\14.0\Search\Setup\ContentIndexCommon\Filters\Extension\.pdf]
@=hex(7):7b,00,45,00,38,00,39,00,37,00,38,00,44,00,41,00,36,00,2d,00,30,00,34,\
00,37,00,46,00,2d,00,34,00,45,00,33,00,44,00,2d,00,39,00,43,00,37,00,38,00,\
2d,00,43,00,44,00,42,00,45,00,34,00,36,00,30,00,34,00,31,00,36,00,30,00,33,\
00,7d,00,00,00,00,00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office Server\14.0\Search\Setup\Filters\.pdf]
"Extension"="pdf"
"FileTypeBucket"=dword:00000001
"MimeTypes"="application/pdf"
sps2010pdf.reg
January 3, 2012 - 07:20, by Steven Van de Craen
Categories: SharePoint 2007
You can configure the permission level of anonymous users to allow for viewing versions of documents and items, but no matter what you do, they get prompted for credentials.
The Version History page has the property “AllowAnonymousAccess” set to false. It is a virtual property in the Microsoft.SharePoint.ApplicationPages.UnsecuredLayoutsPageBase class that needs to be overridden in those layout pages that should be visible for anonymous users.
SharePoint 2007
The solution is an identical copy of the original Version History page of SharePoint 2007 but with the aforementioned property set to true.
The farm solution contains the page and a Site Collection Feature for activation which will add links to the page in the Toolbar and ECB menu for Document Libraries and Lists. You could hide or replace the link to the original page, but that isn’t straight-forward using CustomAction elements.
Installation and activation
Download from here (Ventigrate Codeplex Repository)
Deploy the WSP (farm solution) to the SharePoint Farm
STSADM -o addsolution -filename Ventigrate.Shared.AnonymousVersionHistory.wsp
STSADM -o deploysolution -name Ventigrate.Shared.AnonymousVersionHistory.wsp -allowgacdeployment -immediate
Activate the Site Collection Feature where you want this functionality
SharePoint 2010
SharePoint 2010 suffers from the same issue. You need to adapt the above solution to make it work for SharePoint 2010
- Copy the markup of the SharePoint 2010 Version History page (and add the property override)
- Adapt the CustomAction elements to add links to UI elements for SharePoint 2010 (and optional Dialog UI)
January 3, 2012 - 06:24, by Steven Van de Craen
Categories: SharePoint 2010, Excel Services, Office Web Applications
Recently a colleague wanted to display a with Excel Services rendered workbook inside a cross-domain iframe:
- Excel Services: http://intranet/_layouts/xlviewer.aspx?id=%2FShared%20Documents%2FBook1%2Exlsx&DefaultItemOpen=1
- Other domain web site with iframe: http://lux
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”
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.
You might want to adapt the code for additional checks on referrer, querystring, client, or similar for conditional removal of the header (see final note below).
Installation and activation
Download from here (Ventigrate Codeplex Repository)
Deploy the WSP (farm solution) to the SharePoint Farm
STSADM -o addsolution -filename Ventigrate.Shared.PermissiveXFrameHeader.wsp
STSADM -o deploysolution -name Ventigrate.Shared.PermissiveXFrameHeader.wsp -allowgacdeployment -immediate
Activate the Web Application Feature to the Web Application referred to in the iframe
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.