Tag Archive: NUnit

Tweet

< Part One: Medium Trust primer

< Part Two: Devising a solution

Welcome to part three! We’re going to get some work done on unit testing in Medium Trust. If you want a primer, check out the previous posts. If you came here from there, well hello there recursive sentence!

First things first: the code for the below is all in MIT-licensed Umbraco 5! As you may / may not know, Umbraco 5 will be shipping both a set of Framework assemblies in addition to the core CMS when we release later this year. You can use it all for free, isn’t that grand?

For today, here’s a big unmissable link to download a preview zip of Umbraco.Framework.Testing. It’s MIT licensed and you can use this in your tests real easy. I’ve put it on my DropBox for now – I want to get this post out quick and go to the pub! into your hands! In an upcoming release we’ll make Framework & CMS downloads available as individual zips on CodePlex.

A quick note: I only came up with this last week, so (ironically) Umbraco 5 does not yet support Medium Trust as of today’s Alpha 3 – but the point is, we’ll now be able to use this technique to test our code in partial trust and make it happen reliably, and soon.

If you’d like to download all of the Umbraco codebase and see what other goodies are in our Framework and CMS, visit the repository at http://umbraco.codeplex.com/SourceControl/list/changesets.

To use this in your NUnit tests

I’ll walk through the code in another post, but if you want to jump straight into using this, download the zip, add a reference to Umbraco.Framework and Umbraco.Framework.Testing and you’re set.

Note: Because your tests will call NUnit’s Assert methods, NUnit itself needs to be able to run in partial trust. The zip contains a rebuild of NUnit.Framework.dll – the only change from 2.5.10.11092 is adding the AllowPartiallTrustedCallersAttribute to their assembly. Don’t believe me? Check out my fork at https://bitbucket.org/boxbinary/nunit-2.5x

Your test runner does not need to be rebuilt, so this is still compatible with NUnit’s runner, ReSharper’s runner, TeamCity etc.; only your own code referencing the NUnit Framework needs to reference the assembly.

Once you’ve added the references, let’s make a new fixture called MyCoolFixture. Set the fixture so it inherits from AbstractPartialTrustFixture, like so:

  1. using NUnit.Framework;
  2. using Umbraco.Framework.Testing.PartialTrust;
  3. namespace PartialTrustTest
  4. {
  5. [TestFixture]
  6. public class MyCoolFixture : AbstractPartialTrustFixture<MyCoolFixture>
  7. {
  8. public override void TestSetup()
  9. {
  10. return;
  11. }
  12. public override void TestTearDown()
  13. {
  14. return;
  15. }
  16. }
  17. }



Those TestSetup / TestTearDowns are there for you to put relevant code or just return if nothing’s needed.

Next let’s add a test or two:

  1. using System;
  2. using System.IO;
  3. using System.Runtime.Serialization.Formatters.Binary;
  4. using NUnit.Framework;
  5. using Umbraco.Framework.Testing.PartialTrust;
  6. namespace PartialTrustTest
  7. {
  8. [TestFixture]
  9. public class MyCoolFixture : AbstractPartialTrustFixture<MyCoolFixture>
  10. {
  11. [Test]
  12. public void ThisShouldWork()
  13. {
  14. // Arrange, Act
  15. Console.WriteLine(“Hiyaaa”);
  16. // Assert
  17. Assert.Pass(“Yeah this is a bit pedantic”);
  18. }
  19. [Test]
  20. public void ThisShouldNotWork()
  21. {
  22. // Arrange
  23. var myObject = DateTimeOffset.Now;
  24. // Act
  25. var myClone = Clone(myObject);
  26. // Assert
  27. Assert.Fail(“Wait, why did we get here?”);
  28. }
  29. ///
  30. /// Makes a copy from the object.
  31. /// Doesn’t copy the reference memory, only data.
  32. ///
  33. /// Type of the return object.
  34. /// Object to be copied.
  35. /// Returns the copied object.
  36. public static T Clone(T item)
  37. {
  38. if (item != null)
  39. {
  40. var formatter = new BinaryFormatter();
  41. var stream = new MemoryStream();
  42. formatter.Serialize(stream, item);
  43. stream.Seek(0, SeekOrigin.Begin);
  44. T result = (T)formatter.Deserialize(stream);
  45. stream.Close();
  46. return result;
  47. }
  48. else
  49. return default(T);
  50. }
  51. public override void TestSetup()
  52. {
  53. return;
  54. }
  55. public override void TestTearDown()
  56. {
  57. return;
  58. }
  59. }
  60. }



Nothing crazy, just a simple thing which should work and a simple thing which should not.

What, pray tell, should not? Well, that there Clone method is a really handy, and extremely common extension method that uses binary serialization to give you an exact copy of an object. FluentNHibernate uses it, in fact. But BinaryFormatter tries to set private members, and as we now know you can’t do that in Medium Trust!

So in theory that second test should fail. Let’s run that to see if all my promises are true:

image

Check .. that .. OUT!

SetUp : Umbraco.Framework.Testing.PartialTrust.PartialTrustTestException : Test ThisShouldNotWork fails in a partial trust environment, due to: Request for the permission of type ‘System.Security.Permissions.SecurityPermission, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089′ failed.
—-> System.Security.SecurityException : Request for the permission of type ‘System.Security.Permissions.SecurityPermission, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089′ failed.

So let’s fix the test so TestShouldFail() appropriately asserts that … it should fail:

  1. using System;
  2. using System.IO;
  3. using System.Runtime.Serialization.Formatters.Binary;
  4. using System.Security;
  5. using NUnit.Framework;
  6. using Umbraco.Framework.Testing.PartialTrust;
  7. namespace PartialTrustTest
  8. {
  9. [TestFixture]
  10. public class MyCoolFixture : AbstractPartialTrustFixture<MyCoolFixture>
  11. {
  12. [Test]
  13. public void ThisShouldWork()
  14. {
  15. // Arrange, Act
  16. Console.WriteLine(“Hiyaaa”);
  17. // Assert
  18. Assert.Pass(“Yeah this is a bit pedantic”);
  19. }
  20. [Test]
  21. public void ThisShouldNotWork()
  22. {
  23. // Arrange
  24. var myObject = DateTimeOffset.Now;
  25. // Act & Assert
  26. Assert.Throws<SecurityException>(() => Clone(myObject));
  27. }
  28. ///
  29. /// Makes a copy from the object.
  30. /// Doesn’t copy the reference memory, only data.
  31. ///
  32. /// Type of the return object.
  33. /// Object to be copied.
  34. /// Returns the copied object.
  35. public static T Clone(T item)
  36. {
  37. if (item != null)
  38. {
  39. var formatter = new BinaryFormatter();
  40. var stream = new MemoryStream();
  41. formatter.Serialize(stream, item);
  42. stream.Seek(0, SeekOrigin.Begin);
  43. T result = (T)formatter.Deserialize(stream);
  44. stream.Close();
  45. return result;
  46. }
  47. else
  48. return default(T);
  49. }
  50. public override void TestSetup()
  51. {
  52. return;
  53. }
  54. public override void TestTearDown()
  55. {
  56. return;
  57. }
  58. }
  59. }



And run it:

image

Woo!

But what if I want some tests to literally only test something in full-trust?

Well, you can of course have full-trust tests in a separate fixture. OR, you could decorate the test with the [TestOnlyInFullTrust] attribute I’ve added to our library. I’ll change the test again to demonstrate:

  1. [Test]
  2. public void ThisShouldNotWorkInFullTrust()
  3. {
  4. // Arrange
  5. var myObject = DateTimeOffset.Now;
  6. // Act & Assert
  7. Assert.Throws<SecurityException>(() => Clone(myObject));
  8. }
  9. [Test]
  10. [TestOnlyInFullTrust]
  11. public void ThisShouldWorkOnlyInFullTrust()
  12. {
  13. // Arrange
  14. var myObject = DateTimeOffset.Now;
  15. // Act & impicitly Assert
  16. Clone(myObject);
  17. }



And run:

image

Sweet!

So, there you have it. Easy partial-trust testing by inheriting from one base class.

In the next post – which may be next week, at this rate – I’ll walk through the code and explain how it works, for example if you’d like not to inherit from another class and just want to spin up an individual test yourself in a partial trust context individually.

We can also look into making this work with other testing frameworks, if you’re really nice.

Hope this helps you; let me know if so!

Tweet

This post originally started out life as a three-paragraph thing, but then I realised the topic really merits a lot of background, so I thought I’d get with the cool gang and do a multi-part post.

First, I’m going to cover a bit of background about Medium Trust, and how to understand what it actually means for your code in terms of permissions.

The second post covers a solution I’ve produced over the past week and in the latest build of Umbraco.Framework.Testing which allows you to easily ensure all your NUnit tests run in partial trust.

The third post has the download and some instructions, so jump there if you want to cut to the chase.

In these posts I’ll be talking about .NET 3.5 and above – just to be clear from the outset.

Medium Nightmare

image

Medium Trust is probably one of the most infamous parts of an ASP.NET developer’s coding life. If you work on your own applications, hosted in Full Trust environments under the control of you or your team, you’re fine. You may have never even come across an issue. It’s this phenomenon which has created such a painful situation: so many developers write code which they reasonably expect can be deployed anywhere; it passes its tests, and works on their machine.

But if you’ve ever put together a website with some cool fandangled bit of code that runs fine locally, and then you’ve deployed it to your hosting account, only to find your beautiful creation misses you dearly and is just sat there screaming complaints of SecurityPermission this, and FieldAccessPermission that, you’ll know how tough it can be.

For many it’s the beginning of a very long and arduous process of re-engineering and debugging in what can seem like an infinite loop, and many assumptions about the way the application works (such as lazy-loading proxies in NHibernate) often need to be entirely revisited. Or not, depending on how much luck you have with your Bing search. It’s another large part of the problem: it’s such a minefield, even searching for solutions can be spotty.

It’s not all in your hands either; it’s an easy mistake to make precisely because it’s so difficult to test in a reliable way and it’s so easy to begin developing in the default setting for many ASP.Net project templates, which is: Full Trust. Fluent NHibernate, AutoMapper, certain setups of Castle DynamicProxy, of NHibernate – these are Big Name Libraries, and they all have problems. We’ve all been there: Umbraco included up until the past year or so. It’s a long list – and unpicking the problems one by one, rebuilding, and pressing F5 in your browser is a pain in the arse.

I don’t like pains in my arse, and since we’re busy building Umbraco 5 right now, I’d rather we don’t become one in yours either. I figured the other features we’re coding have test coverage, let’s get the Medium Trust issue covered too. And since it’s all open source, everyone can do it. Yeay!

Security background – what exactly is Medium Trust and its permissions?

“Medium Trust” is a loose term for a set of Code Access Security policy settings that offer less freedom to bend the server to your every will. It’s complicated by the fact that what constitutes “medium trust” is actually a set of permissions listed in configuration, and some hosting companies tailor the settings, so you don’t quite know what you’re dealing with. But in general the policy means at least the following permissions:

  • AspNetHostingPermission of “medium” – For example, a minimum requirement that calls to public types in the System.Web namespace must be coming from code that is granted at least a certain “minimal” trust level.
  • A DnsPermission which is unrestricted. Go mad on those Dns lookups.
  • An EnvironmentPermission which grants access only to the following system environment variables by default:
    • TEMP; TMP; USERNAME; OS; COMPUTERNAME
  • A FileIOPermission that says you may only Read, Write, Append and browse the filesystem that starts with the root of your website and nowhere else. Shocker.
  • An IsolatedStorageFilePermission which permits isolation of storage first by user, and then by code assembly. It allows you a data store for the assembly that is accessible in any domain context.
  • Bizarrely, a PrintingPermission which permits programmatic printing to the default printer.
  • A SecurityPermission which allows the following flags:
    • Execution (to allow managed code to execute – yeay!)
    • ControlPrincipal (to manipulate the Principal object i.e. set the current logged-on user)
    • ControlThread (to allow the totally unambiguous “certain advanced operations on threads”, thanks MSDN!)
    • RemotingConfiguration (to configure Remoting types and channels)
  • An SmtpPermission which allows you to connect only to port 25
  • An unrestricted SqlClientPermission
  • An unrestricted TypeDescriptorPermission
  • An unrestricted WebPermission (confused? This actually signifies unrestricted access to make HTTP requests to other services)
  • And finally the one which crops up most often, a ReflectionPermission with flags of RestrictedMemberAccess. This signifies “partially trusted code can access nonpublic types and members, but only if the grant set of the partially trusted code includes all permissions in the grant set of the assembly that contains the nonpublic types and members being accessed”. Again, thanks MSDN! In practice, this means you can’t access private members of someone else’s assemblies – and this is what brings down most libraries.

What’s important about this set of permissions is actually what it doesn’t give you. For example, let’s look at some of the SecurityPermissionFlags you could have won:

  • Calling unmanaged code
  • Ability to provide serialization services
  • Ability to create and manipulate AppDomains

Or the “MemberAccess” ReflectionPermissionFlag, which would have allowed you to use reflection to operate on all members of a class (even its privates).

Also, no OleDbClientPermission or OdbcClientPermissions are in there by default – most hosting companies add these to their Medium Trust configurations.

And certainly no RegistryPermission.

How do you know this and where is it configured?

Well, perhaps the wider point is I don’t know this by reading one handy straightforward piece of simple documentation. The top Google result for me is a piece of “retired” MSDN content left there for reference or for anyone who has run out of everything else to read in the world ever. The top Bing result is an MSDN video from 2005. I’m sure it’s very good, but it’s an exe file download. From 2005.

90% of what you need to know about Medium Trust’s permission set is stored in the web_mediumtrust.config file for the .NET version on which your application is running. On my machine, for .NET 4, that’s C:\Windows\Microsoft.NET\Framework\v4.0.30319\Config\web_mediumtrust.config.

Web_MediumTrust.config explained

The config file has a simple job: declare named sets of permissions. It does this by first declaring a list of SecurityClass elements to predefine the type names of the permissions and give them a key, and then goes on to declare PermissionSet elements which refer back to those types and pass in arguments. Here is the one installed on my dev machine in full:

  1. <configuration>
  2. <mscorlib>
  3. <security>
  4. <policy>
  5. <PolicyLevel version=“1″>
  6. <SecurityClasses>
  7. <SecurityClass Name=“AllMembershipCondition” Description=“System.Security.Policy.AllMembershipCondition, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″/>
  8. <SecurityClass Name=“AspNetHostingPermission” Description=“System.Web.AspNetHostingPermission, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″/>
  9. <SecurityClass Name=“DnsPermission” Description=“System.Net.DnsPermission, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″/>
  10. <SecurityClass Name=“EnvironmentPermission” Description=“System.Security.Permissions.EnvironmentPermission, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″/>
  11. <SecurityClass Name=“FileIOPermission” Description=“System.Security.Permissions.FileIOPermission, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″/>
  12. <SecurityClass Name=“FirstMatchCodeGroup” Description=“System.Security.Policy.FirstMatchCodeGroup, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″/>
  13. <SecurityClass Name=“IsolatedStorageFilePermission” Description=“System.Security.Permissions.IsolatedStorageFilePermission, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″/>
  14. <SecurityClass Name=“NamedPermissionSet” Description=“System.Security.NamedPermissionSet”/>
  15. <SecurityClass Name=“PrintingPermission” Description=“System.Drawing.Printing.PrintingPermission, System.Drawing, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a”/>
  16. <SecurityClass Name=“SecurityPermission” Description=“System.Security.Permissions.SecurityPermission, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″/>
  17. <SecurityClass Name=“SmtpPermission” Description=“System.Net.Mail.SmtpPermission, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″/>
  18. <SecurityClass Name=“SqlClientPermission” Description=“System.Data.SqlClient.SqlClientPermission, System.Data, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″/>
  19. <SecurityClass Name=“StrongNameMembershipCondition” Description=“System.Security.Policy.StrongNameMembershipCondition, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″/>
  20. <SecurityClass Name=“TypeDescriptorPermission” Description=“System.Security.Permissions.TypeDescriptorPermission, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″/>
  21. <SecurityClass Name=“UIPermission” Description=“System.Security.Permissions.UIPermission, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″/>
  22. <SecurityClass Name=“UnionCodeGroup” Description=“System.Security.Policy.UnionCodeGroup, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″/>
  23. <SecurityClass Name=“UrlMembershipCondition” Description=“System.Security.Policy.UrlMembershipCondition, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″/>
  24. <SecurityClass Name=“WebPermission” Description=“System.Net.WebPermission, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″/>
  25. <SecurityClass Name=“ZoneMembershipCondition” Description=“System.Security.Policy.ZoneMembershipCondition, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″/>
  26. <SecurityClass Name=“ReflectionPermission” Description=“System.Security.Permissions.ReflectionPermission, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″/>
  27. </SecurityClasses>
  28. <NamedPermissionSets>
  29. <PermissionSet
  30. class=“NamedPermissionSet”
  31. version=“1″
  32. Unrestricted=“true”
  33. Name=“FullTrust”
  34. Description=“Allows full access to all resources”
  35. />
  36. <PermissionSet
  37. class=“NamedPermissionSet”
  38. version=“1″
  39. Name=“Nothing”
  40. Description=“Denies all resources, including the right to execute”
  41. />
  42. <PermissionSet
  43. class=“NamedPermissionSet”
  44. version=“1″
  45. Name=“ASP.Net”>
  46. <IPermission
  47. class=“AspNetHostingPermission”
  48. version=“1″
  49. Level=“Medium”
  50. />
  51. <IPermission
  52. class=“DnsPermission”
  53. version=“1″
  54. Unrestricted=“true”
  55. />
  56. <IPermission
  57. class=“EnvironmentPermission”
  58. version=“1″
  59. Read=“TEMP;TMP;USERNAME;OS;COMPUTERNAME”
  60. />
  61. <IPermission
  62. class=“FileIOPermission”
  63. version=“1″
  64. Read=“$AppDir$”
  65. Write=“$AppDir$”
  66. Append=“$AppDir$”
  67. PathDiscovery=“$AppDir$”
  68. />
  69. <IPermission
  70. class=“IsolatedStorageFilePermission”
  71. version=“1″
  72. Allowed=“AssemblyIsolationByUser”
  73. UserQuota=“9223372036854775807″
  74. />
  75. <IPermission
  76. class=“PrintingPermission”
  77. version=“1″
  78. Level=“DefaultPrinting”
  79. />
  80. <IPermission
  81. class=“SecurityPermission”
  82. version=“1″
  83. Flags=“Execution, ControlThread, ControlPrincipal, RemotingConfiguration”
  84. />
  85. <IPermission
  86. class=“SmtpPermission”
  87. version=“1″
  88. Access=“Connect”
  89. />
  90. <IPermission
  91. class=“SqlClientPermission”
  92. version=“1″
  93. Unrestricted=“true”
  94. />
  95. <IPermission
  96. class=“TypeDescriptorPermission”
  97. version=“1″
  98. Unrestricted=“true”
  99. />
  100. <IPermission
  101. class=“WebPermission”
  102. version=“1″
  103. Unrestricted=“true”
  104. />
  105. <IPermission
  106. class=“ReflectionPermission”
  107. version=“1″
  108. Flags=“RestrictedMemberAccess”/>
  109. </PermissionSet>
  110. </NamedPermissionSets>
  111. <CodeGroup
  112. class=“FirstMatchCodeGroup”
  113. version=“1″
  114. PermissionSetName=“Nothing”>
  115. <IMembershipCondition
  116. class=“AllMembershipCondition”
  117. version=“1″
  118. />
  119. <CodeGroup
  120. class=“UnionCodeGroup”
  121. version=“1″
  122. PermissionSetName=“ASP.Net”>
  123. <IMembershipCondition
  124. class=“UrlMembershipCondition”
  125. version=“1″
  126. Url=“$AppDirUrl$/*”
  127. />
  128. </CodeGroup>
  129. <CodeGroup
  130. class=“UnionCodeGroup”
  131. version=“1″
  132. PermissionSetName=“ASP.Net”>
  133. <IMembershipCondition
  134. class=“UrlMembershipCondition”
  135. version=“1″
  136. Url=“$CodeGen$/*”
  137. />
  138. </CodeGroup>
  139. </CodeGroup>
  140. </PolicyLevel>
  141. </policy>
  142. </security>
  143. </mscorlib>
  144. </configuration>



When ASP.Net spins up the AppDomain for your website, it checks the <trust> element of your web.config file (which may be inherited from a parent config that the hoster has set), and then goes to the appropriate config file to load the right set of permissions needed for the AppDomain. After that, it’s all down to security which is built-in to the CLR which transparently checks the caller’s permissions vs the callee’s permission demands when running managed code.

Can you see where I’m going with this?

Let’s get on to how and why this matters to us. In the next post I’ll outline how we can use this information to restrict tests to a very similar set of permissions.