I’ve been spending a bit of time testing my ASP.NET West Wind Web Store application in medium trust, and it’s been a hit or miss situation finding little things here and there that don’t work. I’m big on framework code, so I have lots of generic code in my base framework and some of this code has been choking on some of the limited permissions that are available. Fortunately most of these are relatively easy to work.
But there are a few that are problematic and not quite so easily worked around:
ReflectionPermission
Medium trust doesn’t have access to protected members for Reflection. This is a problem for me because I use a custom databinding scheme which uses Reflection to connect properties and data fields to control properties. Example: Binding a business object entity to a TextBox.Text value. In most ‘normal’ situations you would declare the business object as:
protected busInvoice Invoice;
and using Reflection on that isn’t going to work.
WebPermission
Medium trust allows only HTTP access to the same domain. Ouch! I use the WebRequest class for Credit Card Authorization, and that fails with the default permissions.
SocketPermission
Similar situation for a custom SMTP class I’ve been using. I can get around this by using the new System.Net SMTP class, but I haven’t gotten around to convert my class to it yet.
UnmagedCode SecurityPermission
This is required when using some of the Credit Card interfaces provided by the credit card vendors. Verisign PayFlowPro and LinkPoint both use COM interfaces (although LinkPoint has a C API that one can wrestle with). Both also tout a .NET interface, but both provide only COM Interop wrappers around the COM APIs (although I haven’t checked recently).
With the ReflectionPermissions off, my app runs. I’ve had to make a few changes marking members as public where I ordinarily wouldn’t but I can live with that. The other two are more criticial as there’s no clear workaround. Specifically the WebPermission one for the Authorize.NET, AccessPoint, BluePay interfaces or the UnmagedCode permissions when LinkPoint or PayFlow are used have no real workarounds.
So, to make this fly I’m shipping a WebStoreMedium.config file with the app that allows limited enabling of functionality without having to go to full trust all out. Depending on what features are used one or two things might need to be enabled.
So what do you need to do?
<configuration>
<mscorlib>
<security>
<policy>
<PolicyLevel version="1">
<SecurityClasses>
<!-- West Wind Web Store Added Security Classes -->
<SecurityClass Name="ReflectionPermission" Description="System.Security.Permissions.ReflectionPermission, mscorlib, Version=2.0.0.0, Culture=neutral,PublicKeyToken=b77a5c561934e089"/>
<SecurityClass Name="SocketPermission" Description="System.Net.SocketPermission, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"/>
<!-- End West Wind Web Store Added Security Classes -->
…
First thing is to add any non-defined SecurityClass entries for the permissions required. In my case the ReflectionPermission and SocketPermissions needed to be added. This entry only sets up the permissions that can be addressed, not the actual permissions available for it.
Note that these permissions must be specified with their full strong name. The easiest way to find these permissions is by looking the base web.config in the .NET Configuration directory (C:\Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG). Here you can find the default web.config as well as high trust and low trust versions of these files and in them you can find the various permission definitions.
Next are the permission sets and the actual permissions that need to get set:
<NamedPermissionSets>
<PermissionSet
class="NamedPermissionSet"
version="1"
Unrestricted="true"
Name="FullTrust"
Description="Allows full access to all resources"
/>
<PermissionSet
class="NamedPermissionSet"
version="1"
Name="Nothing"
Description="Denies all resources, including the right to execute"
/>
<PermissionSet
class="NamedPermissionSet"
version="1"
Name="ASP.Net">
<!-- West Wind Web Store Specific Permissions Adjustments -->
<IPermission class="ReflectionPermission"
version="1"
Unrestricted="true" />
<IPermission
class="WebPermission"
version="1"
Unrestricted="true" />
<IPermission
class="SocketPermission"
version="1"
Unrestricted="true" />
<!-- West Wind Web Store Specific Permissions Adjustments -->
…
<IPermission
class="SecurityPermission"
version="1"
Flags="Assertion, Execution, ControlThread, ControlPrincipal, RemotingConfiguration,UnmanagedCode"
/>
…
</PermissionSet>
</NamedPermissionSets>
Each individual permission has its own set of properties, but in most cases you can enable them outright by setting the Unrestricted="true". In the case of Web and Socket Permissions there are options for limiting domain or IP addresses for example.
Again to see settings available it’s often easiest to look in the base files to see what settings are made for the full-trust scenario and add these in.
While all of this works, I really wonder whether this will fly with an ISP. An ISP isn’t going to let you make changes at the application level like this. Nevertheless I think it’s a good idea to have a ready-made file like this available so it can be handed off to an ISP to let them know exactly what permissions you might need for an application. After all if you need to do CC processing with Authorize.NET for example, there’s no real way around having the appropriate rights to do HTTP Access.
I’d be curious to hear what others are doing with typical ISP setups. I’ve always been lucky enough either to run on my own boxes or have flexible ISPs, so I can’t say anything about how hard ass ISPs get about this. I would appreciate some feedback in this area…
Other Posts you might also like