Monday, November 29, 2004
Security related decorators for MbUnit

The next version (greater than 1.0.903d) contains a bunch of decorators that will deny access to file, file dialog, sql client, oracle client, etc... The decorators are located in the MbUnit.Framework.1.1.dll in the MbUnit.Framework.Security namespace.

For example you can deny access to the SqlClient using the following:

using MbUnit.Core.Framework;
using MbUnit.Framework;
using MbUnit.Framework.Security;
[TestFixture]
public class MyFixture
{
    [Test]
    [DenySqlClient]
    public void AccessDatabase()
    {
        // access to SQL client will fail in this method.
    }
}
posted on Monday, November 29, 2004 8:49:00 AM UTC  #    Comments [11]
Tracked by:
"card cash gold uk" (online) [Trackback]
Monday, June 06, 2005 4:48:03 PM UTC
Peli's Blog
Monday, June 06, 2005 4:48:03 PM UTC
sweeeeeet. now this is solid unit testing. solid easy to use view into what happens when things fail!
dru
Monday, June 06, 2005 4:48:03 PM UTC
I really like the concept of disallowing access to specific types. Do you think this could be made more extensible by allowing a [Deny(typeof)] syntax?
Ryan Rinaldi
Monday, June 06, 2005 4:48:03 PM UTC
I'll what I can do but the concept does not generalize as easily as it seems. For each permission there are some custom parameters to set. Generally, each permission takes different Enum parameters, etc which makes it difficult that have a generic Deny implementation.
<br>
<br>
Jonathan de Halleux
Monday, June 06, 2005 4:48:03 PM UTC
I don't see these decorators (or the <a title="MbUnit, Generating Unit Testing and Model Based Testing Framework for .NET Framework" href="http://mbunit.tigris.org" target="_blank">MbUnit</a>.Framework.Security namespace) in the latest version - 1.0.915d.
<br>
<br>I can't wait to replace my home-grown version of permission testing.
Dave Montgomery
Monday, June 06, 2005 4:48:03 PM UTC
Make sure you reference the <a title="MbUnit, Generating Unit Testing and Model Based Testing Framework for .NET Framework" href="http://mbunit.tigris.org" target="_blank">MbUnit</a>.Framework.1.1.dll assembly, that's where they are located. (This assembly is compiled against 1.1)
Jonathan de Halleux
Monday, June 06, 2005 4:48:04 PM UTC
They will move in <a title="MbUnit, Generating Unit Testing and Model Based Testing Framework for .NET Framework" href="http://mbunit.tigris.org" target="_blank">MbUnit</a>.Framework.dll soon enough...
Jonathan de Halleux
Monday, June 06, 2005 4:48:04 PM UTC
My bad. Either the 1.0 install didn't work or (more likely) I downloaded 1.0 and forgot to install. Silly me.
Dave Montgomery
Monday, June 06, 2005 4:48:04 PM UTC
Works like a charm. I found a bug almost immediately as I wasn't protected the call to new DirectoryInfo inside my SecurityException handler. Would it make sense to extend the DenyFileIO attribute to be able to apply arbitrary permissions to arbitrary paths? That's one thing that &lt;a href=&quot;<a target="_new" href="http://bigeasy108.blogspot.com/2004/10/programatically-changing-file.html&quot;&gt;my">http://bigeasy108.blogspot.com/2004/10/programatically-changing-file.html&quot;&gt;my</a> current solution&lt;/a&gt; provides which stops me from throwing it away completely.
Dave Montgomery
Monday, June 06, 2005 4:48:04 PM UTC
It should be straight forward to set up. I'll add that the possibility to specify a multiple path in the next release and possibly multiple permissions.
Jonathan de Halleux
Monday, June 06, 2005 4:48:04 PM UTC
thanks we can searched the web.
findz
Comments are closed.

Page rendered at Friday, August 08, 2008 7:31:03 AM UTC