Recently we were stumped by a very strange issue with Sharepoint 2010 publishing page library where we were unable to give users access on one page in pages library.
The way it is supposed to work is
1. We break inheritance for a particular page(Say page P) in pages library
2.Give read access to user A on Page P
3. User A automatically gets Limited Access on pages library ,site and site collection
4.User A directly accesses the Page
Expected result :Page P is displayed
Actual result:User gets access denied
We initially suspected that there was some code on the page that was accessing data/resources that user did not have access to and hence throwing access denied. So we started our small witch hunt,these are the steps we did
1.Checked code for webparts to make sure all code was in elevated privileges
2.Removed all webparts
3.Experimented with out of box page layouts and master pages
None of them seemed to work. Only thing that worked was giving Read access to User A on Pages library.
This option was not acceptable as user A gets access to every page inheriting permissions from pages library
Finally we were also able to replicate this on Out of box sharepoint publishing site.
It seems it is a BUG in sharepoint.
See MS blog for details http://blogs.technet.com/b/stefan_gossner/archive/2011/11/14/interesting-access-denied-problem-on-publishing-pages.aspx
In a nutshell in publishing site if you have enabled content approval and also use minor versions, you need to give users read access to the pages library. This is a bug in Microsoft.SharePoint.Publishing.Internal.ScheduledItemEventReceiver . It checks for all event receivers attached to the page and this required read access to library.This is called when Schedule button is enabled in Ribbon
We then tried to simply not load the control and disabled ribbon but still the same issue persisted, so we know that it is not limited to ribbon control but the whole page itself.
So if you really need to use this functionality ,the only easy solutions you have at the moment are
- Disable content approval workflow on that pages library
- Make sure no page inherits permissions,so even if you have to give users read access to pages library it wont matter because all pages are protected: But again if you use content deployment ,you have another problem :Content deployment many a times resets page permissions on target/rendering system,IE all pages start inheriting permissions. If this happens all users get access to all pages on rendering server even though they don’t have it on authoring.
As luck would have it ,we were using content deployment also and option 1 was not an option ,so we had to actually use a custom solution to protect our pages .A detailed post on it coming soon
