Access denied for anonymous users on list webparts RRS feed

  • Question

  • Hi,

    I have problem with list webparts on Sharepoint foundation web site with anonymous access allowed.

    Here is the configuration:

    1. Sharepoint Foundation on win 2008 r2 server in standalone mode.

    2. Anonymous access is allowed on the web site

    3. All permissions are inherited from the top level site (anonymous users have reading allowed)

    4. I've created custom xsl templates for rendering list content. They are all stored in Site Assets Library

    5. I've added standard OOB list webparts to my webpart pages and linked those webparts to my custom xsl files.

    6. everything works fine

    7. But when I do an iisreset and try to reach my webpart page as anonymous user I get: "access denied. you do not have permission to perform this action or access this resource." error

    8. When authenticated user visits problematic page everything is fine for anonymous user too. (Visiting page as authenticated user is enough)

    9. While I'm receiving an error, when I try to access xsl file it shows up in a browser so the xsl file itself is accessible.

    Anyone has an idea? There is no custom code here or some references it is just plain old list web part with xsl file.

    It looks like cache problem but I'm not sure

    Drasko Popovic
    Wednesday, December 1, 2010 2:47 PM


  • I think the trick is to use xsl:import in the file that is specified in wp properties to reference another xsl which contains your view styles. Requires using 2 xsl files but works around anonymous cache bug
    Wednesday, October 31, 2012 3:48 AM

All replies

  • Quick update:

    1. OOB list webparts (like tasks and announcements) - without XSL links are working fine.

    2. When I visit problematic pages as authenticated user everything works fine for a while, but after an hour or two error is raised again.

    Drasko Popovic
    Wednesday, December 1, 2010 4:57 PM
  • How are you doing #5?  How are you "linking" them?  There are certain things that don't work for anonymous users, such as when you connect web parts together even if the page and the lists/libraries are all accessible individually.  My guess is it's whatever is providing that "link" is that makes it not work for anonymous users.
    SharePoint Architect || Microsoft MVP || My Blog
    Planet Technologies || SharePoint Task Force
    Wednesday, December 1, 2010 6:26 PM
  • Here is explanation for #5.

    5.1 Edit page -> Insert->Web Part

    5.2 From "Lists and libraries" section of the web part panel I choose my list (Announcements for example)

    5.3. Then I click on "Edit Web part" menu item for the web part I previously added

    5.4 In Miscellaneous section of the list web part in the XSL Link field I add url to my XSL file (/SiteAssets/Bios.xsl for example) 


    That's all. SiteAssets is the standard document library. Web part I've added is the standard list web part that sharepoint creates when you create the list. Both of them are enabled for anonymous users.

    When authenticated user visits this kind of page it shows OK for anonymous user too. 

    Drasko Popovic
    Thursday, December 2, 2010 7:42 AM
  • And when you remove that XSL link, does the page work for anonymous users?
    SharePoint Architect || Microsoft MVP || My Blog
    Planet Technologies || SharePoint Task Force
    Thursday, December 2, 2010 7:48 AM
  • yes it is working. Well to be clear, page itself is working all the time. Everything is rendered except this web part. Instead of web part I get "Access denied ..." message.
    Drasko Popovic
    Thursday, December 2, 2010 8:11 AM
  • yes it is working. Well to be clear, page itself is working all the time. Everything is rendered except this web part. Instead of web part I get "Access denied ..." message.
    Drasko Popovic

    But does it 100% work without any errors or any restrictions when you remove that XSL link from the web part?  That's what I'm trying to determine here...that the XSL link is what is causing it.
    SharePoint Architect || Microsoft MVP || My Blog
    Planet Technologies || SharePoint Task Force
    Thursday, December 2, 2010 3:30 PM
  • yeah page works 100% when I remove xsl link.
    Drasko Popovic
    Thursday, December 2, 2010 6:38 PM
  • I was able to reproduce this problem. It will also occur if the xsl is updated. So:

    1. anon user views page successfully

    2. authenticated user uploads new copy of xsl, but does not browse page

    3. anon user gets access denied

    4. authenticated user views page

    5. anon user may now access the page.

    The log file has a little more info on it:

    System.UnauthorizedAccessException: Access is denied. ......    at Microsoft.SharePoint.Library.SPRequest.UpdateWebPartCache....

    That makes a little sense: SharePoint does not run the transform on the xml and xsl each time. It does it once and caches it. But, the anon user doesn't have permission to do this!


    I'll add this to my list of things that SP has difficulty with when it comes to anonymous:



    Mike G.


    • Edited by m g Thursday, December 2, 2010 8:11 PM typo
    Thursday, December 2, 2010 8:09 PM
  • Yes it looked like a cache problem from the beginning.

    But I also noticed one more thing:

    When I turn off "Enable Data View Caching" in Miscellaneous section for problematic web part, I still end up with "Access denied" error.

    Drasko Popovic
    Friday, December 3, 2010 7:34 AM
  • I am having a similar issue, and I have narrowed it down to caching by reducing the cache time (default 86400) to 5 seconds, opening two browser windows - one logged in, one logged out - and refreshing. It's very clear that the anonymous user can only see the data view webpart within the 5 second cache window after the logged in user has viewed the webpart.

    As you must be logged in to actually change the webpart, I've simply increased the cache time on the problematic webpart - however, I am shocked that this behaviour is built into the product: how can SP be the engine behind so many large, public facing websites - when this basic funtionality like this doesn't work??

    Note: I have tested this in two SP Foundation 2010 environments.

    Note2: Both using 'Windows' authentication, I believe...
    • Edited by alirobe Tuesday, September 27, 2011 5:44 AM note2
    Tuesday, September 27, 2011 5:33 AM
  • Hi, did you resolve this issue?


    Visit my blog: http://tuan-tomy.blogspot.com | Visit my forum: http://sharepointvietnam.net
    Saturday, October 15, 2011 2:21 AM
  • Hi Guys,

    I had the same issue, but when I used Content Query web part with custom ItemStyle template it worked.


    1. Add the Content Query Webpart to the page (Publishing Site).

    2. Map the List to the Content Query Webpart.

    3. On the Presentation Section of Content Query tool part. Select the item style (custom item template added to the /Style%20Library/XSL%20Style%20Sheets/ItemStyle.xsl) file using SPD.

    4. Save the Page changes & publish it.

    5. Access the page with anonymous access.



    Tuesday, October 18, 2011 6:16 PM
  • Now I use pretty easy workaround: after editing xsl I open it in browser authorised.

    After that anonymous users see web parts ok.

    I mean not CQWP, but simple xlv web parts.
    Tuesday, November 1, 2011 11:10 AM
  • UP !! I have the same problem ... I can not ask Authenticated Users to log-in and call a web page every 5 Minutes so that the Anonymous users can see a custom XsltListViewWebPart on this page .. We have a public-internet site and it is Server Foundation 2010 so we can not use Content Query Web Part.. can anyone help , please ?
    Wednesday, December 28, 2011 4:18 PM
  • We're having this same problem. We have a document library with about 18 different views based on a category column. Every so often we'll get the Access denied error message for the web part with the following log entry:


    Error while executing web part: System.UnauthorizedAccessException: Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))   at Microsoft.SharePoint.Library.SPRequest.UpdateWebPartCache(String bstrWebUrl, Boolean bAllUsers, String bstrID, Byte[]& ppsaData, Boolean fOMCall)    at Microsoft.SharePoint.WebPartPages.SPWebPartManager.CacheWriteInternal(Guid storageKey, Byte[] cacheData, Storage storage, Boolean omCall)    

     at Microsoft.SharePoint.WebPartPages.BaseXsltListWebPart.get_CustomizedXsl()    

     at Microsoft.SharePoint.WebPartPages.BaseXsltListWebPart.LoadXslCompiledTransform(WSSXmlUrlResolver someXmlResolver)    

     at Microsoft.SharePoint.WebPartPages.DataFormWebPart.GetXslCompiledTransform()    

     at Microsoft.SharePoint.WebPartPages.DataFormWebPart.PrepareAndPerformTransform(Boolean bDeferExecuteTransform)


    This is the workaround:

    1. Login as authorized user
    2. Edit the view with the error, then save.
    3. Refresh the page as authorized user.
    4. Access the page in another browser as anonymous user, view works.

    Obviously this is not a permanent solution since the error seems to pop up rather frequently. This is on a live anonymous page accessed by a lot of people, so we need a permanent fix to this as soon as possible. Are there any KB articles about this problem?

    Edit: Originally I said that no custom XSL was being used, but this was incorrect. I forgot that I had edited each view so the Title column would link to the item instead of the name field (we wanted the file names to have no spaces so that links wouldn't have spaces, but the Title could). So it appears this is the same bug as others have described.

    • Edited by Matt Laney Wednesday, February 15, 2012 5:26 PM Corrected a statement I made about no custom XSL
    Wednesday, February 15, 2012 5:03 PM
  • what event drives to error appearing? Restarting server or something else?
    Thursday, February 16, 2012 8:27 AM
  • We don't really know what causes it. It'll be working fine one day, broken the next. Then we'll fix it and it'll be fine again for a day or so, then broken. 
    • Proposed as answer by ReubeNZ Friday, February 24, 2012 9:18 PM
    • Unproposed as answer by Margriet Bruggeman Monday, April 9, 2012 9:30 AM
    Monday, February 20, 2012 9:48 PM
  • A work around for this one we found could be moving the referenced XSL to the sub site level (such as placing under the local Documents library in the same site where the web part lives) as this issue seems to relate to the anonymous user context under one site not being able to build the cache from a different sub site xsl resource.

    Friday, February 24, 2012 9:25 PM
  • if this one happens intermittently as above it is xsl cache build related and a solution is listed below:
    Friday, February 24, 2012 9:37 PM
  • Hi guys - the post above suggests a solution below, but I can't see any links?

    I'm also having this issue. I'm using a hosted 2010 Foundation environment (ie: no Content Query Web Parts, and no ability to install farm solutions), and using custom XSL on the Blog site's "Posts" web part.

    Same issue as above: Anonymous users get "Access Denied" when trying to access the Blog, until a logged in user access the page in question, refreshing the cache (including for Anonymous).

    The custom XSL (blog.xsl) for Posts is kept in the same web (the Blog site) and the "XSL timeout" is disabled,  but it still occurs intermittently.

    If anyone's come across a solution since, I'm all ears. All other posts I've found end up linking here.

    EDIT: My solution for now has been to set up a script which hits the required blog pages as an authenticated user on a repeating scheduled task. :( Far from ideal, but working for now.
    • Edited by Timothy Boettcher Monday, July 23, 2012 3:03 AM updated repro details and current workaround
    Wednesday, July 18, 2012 7:43 AM
  • My Scenario is same, but I getting following error for contribute access itself

    Error while executing web part: Microsoft.SharePoint.WebPartPages.WebPartPageUserException: Personalization has been disabled for this zone.

    at Microsoft.SharePoint.WebPartPages.SPWebPartManager.ThrowIfCantModifyZone(String zoneID, Boolean throwIfLocked)

    at Microsoft.SharePoint.WebPartPages.SPWebPartManager.ProcessZoneId(WebPart webPart, Boolean throwIfLocked)

    at Microsoft.SharePoint.WebPartPages.SPWebPartManager.SaveChangesInternal(SPLayoutProperties layoutProperties, Boolean skipRightsCheck, Boolean skipSafeAgainstScriptCheck)

    at Microsoft.SharePoint.WebPartPages.BaseXsltListWebPart.get_CustomizedXsl()

    at Microsoft.SharePoint.WebPartPages.BaseXsltListWebPart.LoadXslCompiledTransform(WSSXmlUrlResolver someXmlResolver)

    Please help me to resolve this error

    Tuesday, September 4, 2012 9:39 AM
  • Hello Everyone,

    I have the same problem for our publishing internet site: if the document library web part using default xsl, everything was fine, as long as we put customized xslt file in "XSL Link" box, anonymous use get "Access denied" error. If anyone know the solution, please share it here.

    I really appreciate the helps.

    • Edited by abcds Wednesday, October 17, 2012 6:41 PM
    Wednesday, October 17, 2012 6:40 PM
  • I think the trick is to use xsl:import in the file that is specified in wp properties to reference another xsl which contains your view styles. Requires using 2 xsl files but works around anonymous cache bug
    Wednesday, October 31, 2012 3:48 AM
  • Thanks Joshbooker, this really worked for me too. I also added those two XSL files in document library and published them.

    Thank yo so much for saving a day!!

    Tuesday, March 5, 2013 3:14 PM