May 24, 2011 - 21:10, by Dostalek, Kevin
Some of you may be familiar with a feature named ViewFormPagesLockdown that ships with MOSS 2007 and SharePoint Server 2010. It’s automatically enabled when you create a new site using the publishing template. Basically, if you enable anonymous access then this feature will keep those anonymous users out of application pages and form pages while still allowing them read access to the underlying list/document data. So for example, they can open a publishing page in a Pages library or download a document from a document library, but they are not able to access the page item property view form or view a list of all the documents in the library.
This feature wasn’t present in WSS, but that makes sense since WSS doesn’t support the publishing infrastructure anyway. However, now that we have Wiki Page libraries (/SitePages) available in SharePoint 2010 Foundation (SPF from here on) you very well might want to have that same behavior to lock out anonymous users from the “backstage” of a public facing web site.
Take a look at the screenshot below that was taken from the SharePoint Management Shell running on a SharePoint 2010 Server:
It’s a hidden feature, but no problem on Server; you can simply activate this feature from PowerShell. However, if you run the same command on an SPF server you will get NADA. It’s not installed. What to do?
Well, it turns out that all that this feature does is change a few of the permissions for the Limited Access Role in the site collection. There’s not an easy way to get at that via the web UI, but it’s almost trivial with a tiny bit of code. Here’s a very truncated version of what you need to do:
1: string url="http://yoursite";
2: using(var site = new SPSite(url))
3: {
4: SPWeb rootWeb = site.RootWeb;
5: SPRoleDefinition guestRole = rootWeb.RoleDefinitions.GetByType(SPRoleType.Guest);
6: guestRole.BasePermissions &= ~(SPBasePermissions.EmptyMask | SPBasePermissions.ViewFormPages);
7: guestRole.BasePermissions &= ~SPBasePermissions.UseRemoteAPIs;
8: rootWeb.AnonymousPermMask64 &= ~(SPBasePermissions.UseRemoteAPIs | SPBasePermissions.ViewFormPages);
9: rootWeb.Update();
10: }
For those that would like something a bit more polished, say a well behaved command line application or an actual SharePoint feature you can turn on and off, contact me and I’ll hook you up.
June 20, 2007 - 01:59, by Dostalek, Kevin
So sometimes you need to pop in some code, lets say for example in a web part.. that needs to do something that the user running the webpart doesn't normally have permission to do. There are a couple of solutions possible all relating to various forms of impersonation.
WSS3 adds an extremely easy way (albeit, not necessarily the most secure way, but let's pretend that we trust our developers implicitly, and this DLL is going into the GAC).
SPSecurity.RunWithElevatedPrivileges(delegate codeToRun)
Ok super. But a big gotcha is that if you try and pull SPContext.Current.Web from within the delegate it will return an SPWeb object in the context of the current user, not one with elevated privileges (sort of makes sense if you think about it). Unfortunately in a webpart scenario the context object is pretty key, so here's one work around (I'm sure there are others--- let me know).
//Get data to recreate "context" later with privileges
SPWeb webUserContext = SPContext.Current.Web;
Guid webGuid = webUserContext.ID;
Guid siteGuid = webUserContext.Site.ID;
// run as system administrator
SPSecurity.RunWithElevatedPrivileges(delegate()
{
// get the site in this context
using (SPSite site = new SPSite(siteGuid))
{
// get the web in this context
SPWeb web = site.OpenWeb(webGuid);
// do you stuff here
}
});