If you’ve been developing with SharePoint (or .NET web apps) for awhile, you’re likely aware that it’s generally a good practice to deploy custom code to the BIN directory of the web application and explicitly specify the least set of permissions required to execute the code contained in your assembly. (If you’re interested, here’s a write-up with a link to a slide deck covering this topic in more detail.)
On a recent project, I created a SharePoint application page to be hosted in the layouts directory. The page class inherited from LayoutsPageBase, and the ASPX file was set to inherit from this class/assembly. Pretty straightforward.
As noted above, I wanted to deploy this assembly to the application BIN directory (not GAC) and use a CAS permission policy to allow it to execute within SharePoint. However, when I did that and tried to browse to the page, I got this exception:
Request failed. at System.Reflection.Assembly._GetType(String name, Boolean throwOnError, Boolean ignoreCase) at System.Web.UI.TemplateParser.GetType(String typeName, Boolean ignoreCase, Boolean throwOnError) at System.Web.UI.TemplateParser.ProcessInheritsAttribute(String baseTypeName, String codeFileBaseTypeName, String src, Assembly assembly) at System.Web.UI.TemplateParser.PostProcessMainDirectiveAttributes(IDictionary parseData)
In most other cases in which I’ve gotten permissions errors in the past, the exception has indicated which specific permission I was missing (e.g. SqlClientPermission or FileIOPermission – which is very helpful, as you then know what to fix), but I knew that the issue was security-related, as it worked fine if I deployed to the GAC.
After some head-banging, I started Reflector and took a look at the LayoutsPageBase class (which I should have done much sooner…). The issue was immediately apparent:
1: [PermissionSet(SecurityAction.InheritanceDemand, Name="FullTrust"), PermissionSet(SecurityAction.LinkDemand, Name="FullTrust")]
2: public class LayoutsPageBase : UnsecuredLayoutsPageBase
Note the security attributes on the class. This post has a nice write-up on the specifics of InheritanceDemand and LinkDemand if you’re interested, but the upshot is that you can’t directly call into this class nor inherit from it and call inherited methods without having full trust. A step up the inheritance hierarchy to UnsecuredLayoutsPageBase shows the same attributes there, too.
So here’s the point of this post: you can’t create application pages that inherit from LayoutsPageBase (or UnsecuredLayoutsPageBase) if you want your code to run without full trust.
As I see it, here are the options:
- Deploy to the GAC. The is the easy way out, but for my project (which runs in a shared environment) was not option.
- Deploy to the _app_bin directory. SharePoint ships with a policy file that grants code in the _app_bin directory full trust. Perhaps an option, but it kind of defeats the purpose of CAS, doesn’t it? The point is that I don’t want my code to run fully trusted.
- Inherit from System.Web.UI.Page and manage security yourself. This was the option I chose in the end. You can inherit from the standard ASP.NET page class, but you may simply have to do some of the security things that the layouts base classes were doing for you. For example, the LayoutsPageBase class has a Boolean property called RequireSiteAdministrator, which, if true, ensures that the executing user has site collection admin rights in order to view the page. You can do this type of check yourself; it just takes a little more work. When inheriting from Page, you simply need to ensure that you add the AspNetHostingPermission (with a “Minimal” level) to your CAS declaration and deployment to the BIN with a custom CAS policy works fine.
