I recently experiences this myself in a project and decided to fix it, because the fix is not really that hard. The issue is that when your browser calls http://server/_vti_bin/WACProxy.ashx it receives a 401 error due to it not handling claims.
A WSP for this solution can be downloaded from Codeplex. Note that the WSP will overwrite the existing WACProxy.ashx file, so you might want to create a copy of it first.
What I did was create a wrapper which calls the WACProxy running under elevated privileges instead, and switched out the existing WACProxy.ashx file with one pointing to my assembly.
using System.Web; using Microsoft.SharePoint; namespace mAdcOW.SharePoint { public class WACProxy : IHttpHandler { public void ProcessRequest(HttpContext context) { SPSecurity.RunWithElevatedPrivileges(delegate() { var proxy = new Microsoft.Office.Server.Search.Extended.Query.Internal.UI.WACProxy(); proxy.ProcessRequest(context); }); } public bool IsReusable { get { return false; } } } }
You might thing it’s very very bad running this in an elevated security context and thinking this might create a security hole. But it won’t. What the WACProxy does is sending back script which points to for example http://server/library/_layouts/MobilePageHandler.ashx. This call is then being executed by your browser using your logged in credentials. This means if you don’t have access to the document, you can’t generated a thumbnail for it either.
So we are merely running the call to generate the proper thumbnail URL in an elevated context to get around the claims error.
If you do not want to overwrite or replace the current WACProxy.ashx file, I have a webpart you can drop on the search page which will redirect calls to WACProxy.ashx to YourWACProxy.ash file instead. I will commit this to spsearchparts.codeplex.com at a later time.