We recently acquired a brand new and very powerful server at my company. Its purpose is to act as a host for a very large virtual environment. In getting it prepared for use, I wanted to be able to set it up so many or all of its functions could be administered remotely.

I design, implement, and manage software systems for a living; however, I feel it is important for good developers to engage in more traditional IT-tasks every once in awhile, such as setting up a complicated server and hosting environment. All good engineers or developers should be able to do these things, and it is illuminating for us in terms of knowing what is and is not beneficial for our customers. Simply put, it translates to better software.

Attempting to Connect…

The main administrative interface on Windows 2008 is the Server Manager. Normally, this interface is something you would only see if you are using the server locally, or if you have a RDP session going. I thought it would be neat if one could access this utility from a remote workstation; remote access would allow us to forego the additional and cumbersome step of having to establish a Remote Desktop session to the machine.

The Remote Server Administration Tools for Windows 7 installs a variety of utilities to your workstation, including a Server Manager capable of remotely connecting to a Windows 2008 server.

The reason why I’m writing an article about this, is because it is an utter pain in the ass to get working. I quickly became aware of some very common solutions to issues experienced in remotely connecting a Server Manager session, however none of these solutions worked for me (they were all obvious ones that were too often repeated). I bet a lot of them won’t work for you either. Since I was working off of a normal Windows 2008 machine and normal Windows 7 machine, I can’t help but imagine these issues would probably occur for any and all attempting to do this.

When starting the Server Manager, it would ask me to identify the server I wanted to connect to. After doing so, a message that would become all too familiar was displayed:

Get used to this one.

As you can see, I’m trying to connect to a machine that can be reached by using the FQDN “valid.address.com”. As it should hopefully be obvious to you, in this example I’m having an issue connecting to a real machine using the correct address for that machine.

The Solution

There are a plethora of reasons as to why a connection will fail when attempting to use the Server Manager remotely. If you Google this error message, you will get a billion pages of people complaining about this, and you will see a billion replies sourcing the exact same material which provides some stock solutions found here.

These solutions did not do the trick for me. From what I saw out there on the Internet, it appeared that the issue remained unsolved for most of the people complaining as well.

You are probably familiar with the “Enable remote management of this server from other computers” option found on the Window 2008′s local server manager. While it is great that they provide an option for this, I found that it simply does not do everything that must be done in order to allow for remote access.

I could not find this mentioned ANYWHERE (be it from Microsoft’s official documentation, or third-party support), but things did not start working for me until I installed the WinRM IIS Extension feature on the server. I consider the installing of this feature to be the critical step that ultimately allowed me to use Server Manager remotely.

An Updated Solution

While I was attempting to get the remote Server Manager to work, I made a large number of attempts to fix it; Unfortunately, I can’t exactly say for sure if the installation of the WinRM IIS Extension feature is what did the trick. I have heard of people getting remote Server Manager to work without needing to do this (if I interpreted their words correctly). It may have just been a coincidence.

Another important thing that you’ll want to check is if the Server Manager is making a connection to the correct port. You’ll want the Windows Server 2008 machine’s WinRM listener to be listening on the same port as the client’s WinRM client defaults to. Try out the following and see if it helps.

On the Server

Execute the following in an elevated command prompt:

    winrm enum winrm/config/listener

The above command will output something similar to the following:

    Listener
        Address = *
        Transport = HTTP
        Port = 80
        Hostname
        Enabled = true
        URLPrefix = wsman
        CertificateThumbprint
        ListeningOn = 10.1.10.105, 127.0.0.1

Ok, looks like my listener is using the HTTP protocol on port 80. I have seen it default to something other 80, probably due to other web sites hogging the port; regardless of the port, all we need to do is ensure the client is using this port.

On the Client

Execute the following in an elevated command prompt:

    winrm get winrm/config/client

The above command might output something similar to the following:

    Client
        NetworkDelayms = 5000
        URLPrefix = wsman
        AllowUnencrypted = false
        Auth
            Basic = true
            Digest = true
            Kerberos = true
            Negotiate = true
            Certificate = true
            CredSSP = false
        DefaultPorts
            HTTP = 5985
            HTTPS = 5986
        TrustedHosts = remote.host.com

Hmm, that’s strange: this machine’s WinRM client is defaulting to port 5985 when using HTTP. That certainly isn’t going to work. We need to change the default port to 80. To do this, you can execute the following:

    winrm set winrm/config/client/DefaultPorts @{HTTP="80"}

Yes, a truly inspirational configuration interface!

 

Lately I’ve been experimenting with the newest revision of Microsoft’s Entity Framework (version 4.1 and codenamed “Code First”) in a recent project of mine. Using it has been an interesting experience, and I must express my approval for the design methodology it promotes and makes possible: the ability to create your data model in your code first, and generate an effective database from that. This is the inverse of the more common scenario we see today, which is to have a database first, and then create POCOs from that, more or less. The usefulness of this approach is something that can be debated about some other time, however.

The project I’ve been working on already had a defined (legacy) database schema, therefore my use of the Entity Framework would not concern the generation of new schema from a new data model, but instead had to make use of a schema that did not conform to their corresponding POCOs. There have been a few surprises and stumbling blocks I’ve encountered while working with the framework, and I would like to cover one or more of these stumbling blocks in this post; specifically, I’d like to cover the use of related entities in a class, and how to map the class’s one-to-many relationship with these entities, among other things.

So let’s look at how you would establish the required relational mappings with your model builder when dealing with classes that contain one-to-many references to other entity types, all involving the use of a legacy database.

What We are Working With

Let’s assume we have the following fictitious and very sparse-looking POCO classes:

    public class ResourceReservation
    {
      public int Id { get; set; }

      public DateTime Start { get; set; }

      public DateTime End { get; set; }

      public Resource ReservedResource { get; set; }

      //...other properties go here...
    }

    public class Resource
    {
      public Resource()
      {
        ResourceReservations = new ObservableCollection<ResourceReservation>();
      }

      public int Id { get; set; }

      public string Name { get; set; }

      public virtual ICollection<ResourceReservation> ResourceReservations { get; private set; }

      //...other properties go here...
    }

So we have two entity types here. Before deciding how we map these tables and the relationship between them, we need to look at the preexisting database. So, here is a snapshot of how these tables are defined in this fictitious database:

The tables and columns of those tables that we'll be working with in this example.

As pictured above, we can see a very legacy-looking database, using naming conventions for columns and tables that don’t match up with our POCOs. We can also see that the relationship between the two tables is established via the foreign key that exists within the resourcereservation table, which has been given the lovely name of ‘FKresourcereservationresource’.

When using the Entity Framework as our ORM, it will have certain expectations as to what corresponding entities within the database will be named. This applies to tables, columns, and even foreign keys. So manual specification for all of these items will be required.

Mapping Enhancements

All of the code we’ll be dealing with in order to do this will exist within the OnModelCreating override found in our class that derives fromDbContext. Mapping properties to columns by the column name looks something like the following:

    modelBuilder.Entity<Resource>().Property(rr => rr.Start).HasColumnName("res_start_dt");

    modelBuilder.Entity<Resource>().Property(rr => rr.End).HasColumnName("res_end_dt");

This is sort of clumsy to work with — plus, we are unable to use fluent syntax here; we need to issue separate statements for each mapping, similar to what is shown above. I point that out because I do believe that a fluent syntax was possible in previous versions of the “Code First” iteration of the Entity Framework, namely CTP5, perhaps CTP4?

Using the following extension methods can alleviate some of the pain and allow for fluent syntax:

    /// <summary>
    /// Maps the property specified by the provided property expression to the column whose name matches the specified column name.
    /// </summary>
    /// <typeparam name="TEntityType">The type to be registered or configured.</typeparam>
    /// <typeparam name="TValueType">The value type of the property.</typeparam>
    /// <param name="self">The non-null type of entity that is having a property mapped to it.</param>
    /// <param name="propertyExpression">The expression that declares the property being mapped onto the entity type.</param>
    /// <param name="columnName">The name of the database column the property corresponds to.</param>
    /// <returns>The object this method extends, allowing for a more fluent mapping syntax.</returns>
    /// <remarks>
    /// This is a convenience method. This should be removed if the official EF framework is released with better property -> column
    /// mapping methods.
    /// </remarks>
    public static EntityTypeConfiguration<TEntityType> MapByColumnName<TEntityType, TValueType>(
        this EntityTypeConfiguration<TEntityType> self, Expression<Func<TEntityType, TValueType>> propertyExpression, string columnName)
        where TEntityType : class
        where TValueType : struct
    {
        self.Property(propertyExpression).HasColumnName(columnName);

        return self;
    }
    /// <summary>
    /// Maps the property specified by the provided property expression to the column whose name matches the specified column name.
    /// </summary>
    /// <typeparam name="TEntityType">The type to be registered or configured.</typeparam>
    /// <typeparam name="TValueType">The value type of the property.</typeparam>
    /// <param name="self">The non-null type of entity that is having a property mapped to it.</param>
    /// <param name="propertyExpression">The expression that declares the property being mapped onto the entity type.</param>
    /// <param name="columnName">The name of the database column the property corresponds to.</param>
    /// <returns>The object this method extends, allowing for a more fluent mapping syntax.</returns>
    /// <remarks>
    /// This is a convenience method. This should be removed if the official EF framework is released with better property -> column
    /// mapping methods.
    /// </remarks>
    public static EntityTypeConfiguration<TEntityType>  MapByColumnName<TEntityType, TValueType>(
        this EntityTypeConfiguration<TEntityType> self, Expression<Func<TEntityType, TValueType?>> propertyExpression, string columnName)
        where TEntityType : class
        where TValueType : struct
    {
        self.Property(propertyExpression).HasColumnName(columnName);

        return self;
    }

    /// <summary>
    /// Maps the property specified by the provided property expression to the column whose name matches the specified column name.
    /// </summary>
    /// <typeparam name="TEntityType">The type to be registered or configured.</typeparam>
    /// <param name="self">The non-null type of entity that is having a property mapped to it.</param>
    /// <param name="propertyExpression">The expression that declares the property being mapped onto the entity type.</param>
    /// <param name="columnName">The name of the database column the property corresponds to.</param>
    /// <returns>The object this method extends, allowing for a more fluent mapping syntax.</returns>
    /// <remarks>
    /// This is a convenience method. This should be removed if the official EF framework is released with better property -> column
    /// mapping methods.
    /// </remarks>
    public static EntityTypeConfiguration<TEntityType> MapByColumnName<TEntityType>    (
        this EntityTypeConfiguration<TEntityType> self, Expression<Func<TEntityType, string>> propertyExpression, string columnName)
        where TEntityType : class
    {
        self.Property(propertyExpression).HasColumnName(columnName);

        return self;
    }

Much better.

Mapping our Existing Model

Now, as far as mapping the tables go, we need to provide the following:

  1. The names of the columns the properties should get their values from
  2. Designation as to what property represents the primary key
  3. Any foreign key relationship

As far as foreign key relationships go, a look at the mapping methods tells us that we can establish a relationship with either table, be it the principal or dependent, however I find that it works best if we define the relationship on the class representing that table that actually has the foreign key assigned to it. This means we’ll be defining the relationship in the code responsible for the ResourceReservation class mappings.

The following code provides the mapping needed for the resource table:

    modelBuilder.Entity<Resource>()
      .MapByColumnName(r => r.Id, "resource_id")
      .MapByColumnName(r => r.Name, "resource_name")
      .HasKey(r => r.Id)
      .ToTable("resource")

The specification of the table name in ‘.ToTable(“resource”)’ probably wasn’t necessary; I’m assuming the Entity Framework would have been able to figure out the resource tables name itself, but I’m including it anyway (the corresponding real data type in the project I’m working on doesn’t match up with the table name).

The following code provides the mapping needed for the resource_reservation table:

    modelBuilder.Entity<ResourceReservation>()
      .MapByColumnName(rr => rr.Id, "res_id")
      .MapByColumnName(rr => rr.Start, "res_start_dt")
      .MapByColumnName(rr => rr.End, "res_end_dt")
      .HasKey(rr => rr.Id)
      .ToTable("resource_reservation");

    modelBuilder.Entity<ResourceReservation>()
      .HasRequired(rr => rr.ReservedResource)
      .WithMany(r => r.ResourceReservations)
      .Map(x => x.MapKey("resource_id"))

Note that I’m required to use ‘.Map(x => x.MapKey(“resource_id”))’ because the actual foreign key isn’t exposed on the ResourceReservation object. If it was, then I could use ‘.HasForeignKey(…)’ instead. It needs to be immediately available on the entity object we’re configuring. If I attempted to use ‘.HasForeignKey(rr => rr.ReservedResource.Id)’, I would have gotten an error.

One last thing…

When using EF with a preexisting database, you will need to disable the database initialization strategy, otherwise you will get strange errors during startup. You can do this like so:

    Database.SetInitializer<YourDbContext>(null);
 

Life often presents us with common problems or challenges that require solving. Many problems have many solutions. Some solutions are good; most solutions are bad.

A specific problem developers commonly experience when working with ASP.NET technologies is the age old HttpRequestValidationException problem. Like so many other problems in life, there are many solutions to this one, most of them bad.

A quick Google search will yield many posts that proclaim (many times with a feeling of authority) that the solution here is to disable this pesky security feature. Some tell you to disable it in your web.config, while others indicate that it can be done on the page-level as well by setting validateRequest to false in either place. This security feature exists for a reason, and it is to protect you and your web application from injection (and other kinds of) attacks.

You should embrace this free security feature and make use of it; it is unwise to simply disable it because it is annoying. You can either change your code so that you never enter into a situation where such an exception is raised, or you can keep your code the way it is and take more sensible action.

I. Why Does This Happen?

Referring to the MSDN page on HttpRequestValidationException, we can clearly see that this exception gets raised when a client submits a request containing potentially malicious data. Humorously enough, the first suggestion on the MSDN page is to disable the feature! I wonder where the frequent bad behavior of recommending to disable this feature originates from….

What does “malicious data” entail? It can mean a whole lot of things, I’m sure; most commonly, however when discussing ASP.NET applications, it means HTML elements supplied outside of the original markup. Probably the most common reason as to why this exceptions happens in the wild is due to HTML that isn’t recognized by the server.

How simple the solution on depends on the situation. At times, we might find ourselves working with externally defined HTML that we have no intention of rendering. Other times, however, we may actually WANT to render the externally supplied HTML.

Encoding the HTML before displaying it is a good start. Actually, I believe that used to be all you needed to do (not sure). Starting with .NET 4.0, however, any HTML supplied by the code-behind is going to throw this exception, at least in my experience. Let’s look at a typical example.

Let’s say you have a column of cells that represent the status of an entity. The statuses that are available to use are defined by users or an administrator, and employ HTML in order to style their appearance. So, in order to get that stuff on the page, you load the preference setting (from a database or whatever) and set the cell’s InnerHTML to the user defined HTML.

Now, let’s say the user submits the form. Even though they didn’t directly enter the HTML that makes up the status cells, a request validation exception will occur because the user is submitting a form containing HTML which did not originate from the page’s original markup.

This feature is essentially impossible to provide with request validation turned on.

II. What a Pain, So How Do I Disable This?

No, no, we don’t want to disable it! The fact that you are getting these exceptions means there’s a very real chance that a wide open attack vector exists in your application. You have two options:

  1. Disable the functionality that is allowing for users to direct or indirectly supply some custom HTML completely
  2. Sanitize the input You should first think very hard if such functionality is required. Many times, you may find that there is no good reason as to why you should allow for such a feature. If possible, this will always be the best solution.

Sometimes though, that doesn’t matter one bit. For example, it may be a business requirement. No question there then, you need to make some magic happen.

That leads us to #2, which is the proper thing to do in this case. Sanitize the input. Ok. Let’s say we have a method named “Sanitize”, which takes a string. You run the custom HTML through it, scrub it of all its badness, and then use the result. Submit the form.

You’re still going to get the exception. ASP.NET has no idea if input has been sanitized or not; potentially malicious data is potentially malicious data.

So, is this when you should disable validation for the specific page? Nope, instead, write your own request validator.

III. Custom Validator

And this is the main point of the article.

If you deem a feature where the user can input potentially malicious data is vital, then the proper way of proceeding is to implement your own request validator. This is done by creating a new class that inherits from RequestValidator and registering that class in the web.config so it is used.

So, what’s supposed to go in this validator? I suppose it’s a bit much to assume one can just wave their hand around in a “validator-like” fashion and expect results without knowing what it is they’re supposed to do.

There are many things one can do, and there are many levels of robustness to be had here. I’m going to present you with an example custom validator; I’ll leave it up to you to decide how it can be improved, as it is quite minimal.

The custom validator I’ll be showing here consists of a single method, IsValidRequestString. This is the heart of the show here — this is where all the validation goes down. There’s plenty you can do here, however I’m only doing one thing, I’m looking for known HTML tags that are dangerous, and throwing an error only if one is encountered. I’m not an avowed expect in the ways of typical web application exploitation, therefore do not assume this code will provide you with ironclad security.

The potentially dangerous HTML tags we search for in the code below were compiled by myself from various Microsoft security-related documents.

    protected override bool IsValidRequestString(
        HttpContext context,
        string value,
        RequestValidationSource requestValidationSource,
        string collectionKey,
        out int validationFailureIndex)
    {
        Match dangerousMatch
          = Regex.Match(value,
                         "</?(?i:script|body|applet|html|layer|ilayer|embed|object|frameset|frame|iframe|meta|link|style)(.|\n)*?>",
                         RegexOptions.IgnoreCase | RegexOptions.Compiled);

        // Set this to the location of a match, if one was found.
        validationFailureIndex = 0;

        // Everything is fine here if we failed to find any matches, otherwise ASP.NET will throw an exception.
        return !dangerousMatch.Success;
    }

Basically, all I’m doing is a RegEx match, returning true if there wasn’t a match, false if there was. Returning false from this method will result in the lovely “dangerous request” exception message to appear.

The “validationFailureIndex” set to 0 is an uninitialized integer that must be set before leaving the function. A more correct implementation of this handler would handle this parameter properly, which means that it would be set to the starting point of the text deemed to be malicious in the supplied string.

This will allow for users to use safe HTML, like simple styling elements, while blocking out the nastier elements.

The collection of malicious elements displayed above is a good starting point for knowing what to look for, but I cannot guarantee that these are the only malicious tags out there.

Checking if the HTML in the request was encoded would also be a nice improvement, but that should really be something taken of by the developer, by ensuring everything going out is encoded.

 

Isn’t it a bit of a pain in the ass to have to spell out the name of an offending method argument when throwing an ArgumentNullException? What about when you have to spell out the name of a method you want to invoke dynamically?

Sounds to me like we’re in the early stages of drafting up a large list of liabilities as far as our software is concerned. Every time you have to personally provide a literal in your code, you’re introducing a potential point of fail that will not be caught by the compiler. Literals reflecting intrinsic program characteristics can also very easily make refactoring dangerous.

Look, I know, but…my hands are tied! That’s just the way it is!

No sir, you are very wrong. Instead of slapping sloppy literals all over our code, we can replace them with programmatic elements that’ll cause compilation failure given any compromise in the correctness of these elements.

What would be really nice is if we could get the results of Reflection without having to use Reflection –

Whoa. Whoa man, hold up. Reflection. Huge performance hit man. Huge.

Relax. Reflection operations are expensive to perform, in comparison with other operations in the BCL. You really need to be using it quite a bit for you to be impacted, however.

Well, in our case, if we did use Reflection to somehow retrieve the names of methods, and perhaps the names of parameters to pass to a validation routine that checks for argument correctness…well that’d certainly add up, wouldn’t it?

Let’s see how we can do all of this using Expression trees instead. Unless we are actively compiling Expression trees during run time, we can essentially bypass all penalties normally associated with Reflection by using Expressions instead. Of course what we do is limited to the very definition of Expressions themselves, in that they are merely representations of code.

Expressing the Name of a Method Parameter

Going back to an earlier example, let’s say we want to throw an ArgumentNullException. Well we want to give the exception the name of the offending parameter. So, how can we do this?

When working with lambda expressions, we have several options when it comes to compile-time. We can either compile the lambda expression as a code delegate, or as, you guessed it, an Expression tree.

Creating Expressions via lambda expressions carries many restrictions along with it. More complex Expression trees require the use of the Expression API, which will result in Expressions being generated at run-time, not compile-time, and this cause a performance hit.

But thankfully, we won’t be dealing with a complicated expression tree.

So, here’s a method we could pass the parameter to in order to get its name:

private string ReadPropertyName<TProp>(Expression<Func<TProp>> expression)
{
    // You may want to add validation logic here that checks if the expression
    // is formed correctly.
    MemberExpression body = (MemberExpression) expression.Body;
    return body.Member.Name;
}

How do we pass the parameter to this method? For compile-time creation of Expressions, we can assign a lambda expression to a variable of type Expression<TDelegate>, an example of that being Expression<Func<T>>. Going forward, we can just pass a lambda expression to the ReadPropertyName method, and we’ll have our Expression.

    public string Method(object arg)
    {
        if (null == arg)
            throw new ArgumentNullException(
                ReadPropertyName(() => arg), Resources.MethodArgumentIsNull);
    }

You now have compile-time safety with the use of the parameter’s name, and all without incurring any sort of performance penalty.

Quite a bit of a mouthful we have there though. We’ll probably be doing lots of checking for null inputs if we have many public methods. Also, we can take advantage of using Expressions in many more places than just passing the names of arguments to validation methods, simply think of anywhere you are currently using a string that refers to some sort of code element. In addition to that, we’ll need to be doing this outside of this class.

So, how can we make this a bit more compact and universal?

Well the best we can do here is simply move the logic in ReadPropertyName and all of the null checking logic to some validation utility class. Validation, especially validation in the sense of checking for a null reference, is a concept that can touch every kind of situation and object. Because this is so universal, it is most certainly not bad design to offload general validation procedures to utility classes.

There’s really no way to avoid the requirement of passing the parameter as a lambda expression. Creating an extension method such as “ToLambdaExpression” or something will fail, since that’ll invariably change the expression so that name of the member is whatever is used in the extension method body.

So, let’s make a new utility method in a validation utility class we can use:

    public static void CheckNullArgument<T>(
        T argument,
        Expression<Func<T>> argumentExpression,
        string messageIfNull)
    {
        // Probably want to add validation code for the expression here.
        MemberExpression memberExpression = (MemberExpression) argumentExpression.Body;

        string argumentName = memberExpression.Member.Name;   

        if (argument.IsDefaultOrNull())
            throw new ArgumentNullException(argumentName, messageIfNull);
    }

The IsDefaultOrNull method call you see near the end is an extension method I wrote that is used when I’m working with an object that could either be a reference or value type, and I’m not aware of which. It simply makes use of the default EqualityComparer for the type.

This would be invoked by:

    public IEnumerable<IResourceReservation> Reserve(ReserveParameters parameters)
    {
        Validation.CheckNullArgument(
            parameters, () => parameters, Resources.NullServiceParameters);
    }

We could even make the validation method more general, or at least offer a more general validation routine alongside the null argument check that would simply run some validation criteria against an object and throw an ArgumentException if it fails.

    public static void CheckArgument<T>(
        T argument,
        Expression<Func<T>> argumentExpression,
        Predicate<T> validationCriteria,
        string messageIfFail)
    {
        // Probably want to add validation code for the expression here.
        MemberExpression memberExpression = (MemberExpression) argumentExpression.Body;

        string argumentName = memberExpression.Member.Name;   

        if (!validationCriteria(argument))
            throw new ArgumentException(messageIfFail, argumentName);
    }

This would be invoked by (let’s say if we want to check if a property named StartDate is greater than the current date):

    public IEnumerable<IResourceReservation> Reserve(ReserveParameters parameters)
    {
        Validation.CheckArgument(
            parameters,
            () => parameters,
            x => x.StartDate > DateTime.Now,
            Resources.BadServiceParameters);
    }
© 2012-2013 Matt Weber. All Rights Reserved. Terms of Use.