Rory Primrose

WCF, SSL and localhost

We encountered an interesting issue at work over the last week. We are writing WCF services and implementing transport security to communicate with IIS. For local development, we had certificates created by a certificate server and configured onto the local IIS. As you would expect, the certificates used the machine name for the common name of the certificate. This is after all the standard procedure.

The problem encountered is that the web application project in Visual Studio stores the url of the project in the csproj file rather than the user settings file. This is the url of the application that Visual Studio will attach to in order to debug in IIS. The url has to be a reference to the local machine. As the project is under source control, the url stored as a project setting is now put onto the machines of other developers. So if I configure the project to point to my machine using https, check in the file and another developer gets it, then their version of the project now points to my machine rather than theirs. Bit of a problem.

There were two ideas that we quickly came up with:

1. Modifying the host name file on the local machine (don't know where this one was going, but it was on the table)
2. Adding a WCF hack that hooks into the System.Net.ServicePointManager.ServerCertificateValidationCallback event to ignore certificate errors when the certificate uses the machine name as the common name but the url is localhost

The first solution if it was viable was an issue because it required customisation of every developers machine. Using localhost as a name is the best direction as all machines are already configured with that host name as a loopback. The second idea was probably more viable, but was considered a potential security risk if that code landed in production.

The answer was actually quite simple. Create a certificate with the common name as localhost rather than the specific machine name. This would satisfy the csproj setting pointing to localhost which would be a valid address on all developer machines. Given that all the developer machines needed a certificate anyway, we may as well use localhost as a common name.

The first attempt at this solution actually failed. This is because we created just one localhost certificate and tried to use that on multiple developer machines. The problems seemed to be that when IIS creates a certificate request, a private key is generated such that the resulting issued certificate is only valid for that specific machine, even though localhost was the common name used. Unfortunate, but certainly not a major problem. The answer is that each developer machine needs to create their own IIS certificate request using localhost as the common name. If the url in the csproj points to that address (https://localhost/yourproject/yourservice.svc for example), then this address will work on all developer machines with their own valid certificate.

Static Analysis Rules - Sooner rather than later

I posted the other day that I wanted to create some static analysis rules for Visual Studio. I have some great ideas for several rules that I want to write in order to do two things. Firstly, I want rules to pick up common mistakes made in coding. Secondly, the rules can be used to enforce coding standards via the Code Analysis TFS checkin policy.

To enforce coding standards, I have previously written xpath and regex TFS checkin policy implementations that work off a set of defined rules. I found that the xpath policy worked really well for files like csproj and sln files. The xml in these files is reasonably simple and the xpath queries are able to easily identify data that is missing or data that shouldn't be included. I found it was a different story with the regex policy though. It  became very difficult to be able to satisfy coding standards using regex on code files. It also only allowed for analysis of content within a single file, not what outside code calls into that file or other files that the code calls out to.

Enter the static analysis rules. It turned out that these are really easy to write. In about an hour, I have created four static analysis rules and tested them. The rules so far are:

• ND1001 - Mark DataContract properties with DataMember
• ND1002 - Mark class with DataContract where properties with DataMember exist
• ND1003 - Scope properties marked with a DataMember attribute as public
• ND1004 - Scope classes marked with a DataContract attribute as public

See this post and this post for some pointers about writing your own rules. Given the changes to the Visual Studio 2008 for Static Analysis Rules, some of the information around is not completely correct. I found that using Reflector on the files in C:\Program Files\Microsoft Visual Studio 9.0\Team Tools\Static Analysis Tools\FxCop\Rules gave a great insight about how to achieve some things.

You can download the code for the above rules and included Release build from here. If you want to use these rules, just drop the Neovolve.StaticAnalysis.Rules.dll into C:\Program Files\Microsoft Visual Studio 9.0\Team Tools\Static Analysis Tools\FxCop\Rules, start up Visual Studio and run Code Analysis on a WCF service contract project.

On a side note, static analysis rules are great if you use CodePlex. They will allow you to do some of the things that a checkin policy might do. Given that CodePlex doesn't support checkin policies, this is a great alternative as static analysis rules are just dll's on the client machine (no registration or server configuration!).

Fixed: CS url encoding problem on Vista

I previously posted about a Community Server url encoding problem on Vista. The problem was the urls in the tag cloud where rendering spaces with + rather than %20. On Vista (and Windows Server 2008), this results in a 404 error. At the time I spend a few hours researching the problem but no-one had posted any details about this issue at the time. I started looking into it again yesterday and found that there is now a lot of information about the issue.

It is a security feature of IIS7 that denies double escaping by default (see here, here (#11), here and so many places).

Out of all the information that I read yesterday there is some incorrect and not so good information regarding the workaround (can't call it a fix). What worked for me was to:

1. Open Notepad with elevated privileges
2. Open %windir%\System32\inetsrv\config\applicationHost.config
3. Locate the line <section name="requestFiltering" overrideModeDefault="Deny" /> and replace it with <section name="requestFiltering" overrideModeDefault="Allow"/>
4. Save applicationHost.config
5. Open your web.config
6. Add <system.webServer> <security> <requestFiltering allowDoubleEscaping="True"/> </security> </system.webServer> under the configuration element.
7. Save web.config

Most of the posts I read didn't mention steps 2-4 which I found just gives a 500 internal service error. Other posts indicate that the change in step 6 should be applied to applicationHost.config. I don't think that is a good suggestion as the workaround reduces the security level of IIS and such a change would apply to all web application rather than the one that you specifically need to modify the behavior of.

At the end of the day, it is still a Community Server bug (at least on Vista and Windows Server 2008) as the url encoding should use %20 rather than + for encoding spaces.

Writing your own FxCop rules

Jason Kresowaty has posted an incredible amount of information about creating FxCop rules. I'll get to these one day. One rule I want to write is a rule that checks for properties on a DataContract that are not assigned the DataMember attribute.

US ISV Developer Evangelism Team : Free Software, Students and Technology

This is great news from Microsoft. I remember being a poor uni student when it was difficult to afford even the academic software. Hopefully this deal will come to Australia as well.

US ISV Developer Evangelism Team : Free Software, Students and Technology

Scope Sneak

I came up with a new term today - scope sneak.

Sneak [sneek]: verb, sneaked or snuck, sneak·ing, noun

–verb (used without object)

1. to go in a stealthy or furtive manner; slink; skulk.
2. to act in a furtive or underhand way.
3. British Informal. to tattle; inform.

Something happened at work today when a friend highlighted that some requirements had been snuck into a requirements document he was developing from. It occurred to me that this isn't really scope creep (also seen here). Scope creep to me implies that everyone on the project knows that requirements are being added or changed (usually expanded). This situation was a bit more like requirements were added on the sly, hence scope sneak.

Correct Regular Expression For GUID's

Ever wondered what the correct format of a GUID value is? Ever needed a RegEx to validate a GUID as a string value? Check out Nicholas Allen's latest post for a good hint.