Month: October 2006

Currently [RO]' Http channels don't support client certificates (i.e. client certificates are required in IIS when the option "Require Client Certificates" is selected). Why would you need them anyway? Client certificates are an excellent way of authenticating user and thus restricting the access to your website.

According to Marc, Chief Architect/[RO], client certificates support is planned for RemObjects SDK version 5 – next version.

But what if you need them now? Required change is really not that big but unfortunately isn't easily applicable. So [RO] guys suggested modifying WinInetHttpClientChannel.IntDispatch method where this feature belongs. It is certainly feasible and easy to apply, however I am not that keen to recompiling source codes. Not that it is difficult but when new version arrives you need to re-apply and re-compile.

That's why I went with deriving a new channel out of WinInetHttpClientChannel (note: you'll still need source code). Since IntDispatch method is declared as virtual so it can be overriden. The first pass is to create a derived channel named RhHttpClientChannel, add a X509Certificate2 field to it – we'll keep our client certificate in that field and a constructor that takes a X509Certificate2 as an argument. One more thing is to do done at this point. Since we'll be addressing a private field WinInetHttpClientChannel.fHttpHeader we need some reflection. The reference to this field will be stored in fHttpHeaderPI field and initialized in constructor. Here is the code so far:

public class RhHttpClientChannel: WinInetHttpClientChannel
{
    private X509Certificate2 cert;
    private FieldInfo fHttpHeaderPI;

    public RhHttpClientChannel(X509Certificate2 cert)
    {
        this.cert = cert;
        fHttpHeaderPI = typeof(WinInetHttpClientChannel).GetField("fHttpHeader", BindingFlags.NonPublic | BindingFlags.Instance);
     }

Next, property HttpHeader, which is a wrapper to fHttpHeader, is implemented. Again, with a help of reflection (note that FullTrust will be required since we use reflection). fHttpHeader is a HttpHeader class. The problem is that HttpHeader class is declared as an internal in [RO] SDK assembly and thus can't be directly used. Lucky for us, it derives from Hashtable and we need only its Hashtable properties. So it is gonna be treated as a Hashtable.

private Hashtable HttpHeader
{
    get
    {
        Hashtable value = (Hashtable)fHttpHeaderPI.GetValue(this);
        return value;
    }
    set
    {
        fHttpHeaderPI.SetValue(this, value);
    }
}

Now you have to open WinInetHttpClientChannel source code and copy the entire method above (I won't show the implementation since I can't for legal issues)

private void CopyFromStreamToStream(Stream iSourceStream, Stream iDestinationStream, TransferDirection aDirection)
{
   ...
}

method (it is used by IntDispatch and private and I didn't want to bother with reflection).

Next step is to copy and paste IntDispatch method:

protected override void IntDispatch(Stream aRequestStream, IMessage aResponseMessage)
{
   ...
}

Inside the method fUserAgent with UserAgent and fKeepAlive with KeepAlive have to be replaced.

And the final step is to use the certificate that is passed to the constructor. Add this piece of code right after HttpWebRequest instance creation (first line below):

// original code
lWebRequest = (HttpWebRequest)WebRequest.Create(TargetUrl);
// add this below
if (cert != null)
    lWebRequest.ClientCertificates.Add(cert);

There you go. You have a WinInetHttpClientChannel capable of using client certificates.

If you happen to use RemObjects SDK 4.0 (RO) for an alternative to remoting (I'll discuss the benefits in another post) than you are certainly facing one problem. RO thing doesn't support .net classes as method arguments in favor of interoperability (you can't use .net object graph from a different world, i.e. Delphi, right) – out of the box it supports only common value types (ints, strings, etc.) with some degree of extensibility. This isn't good when you want to push a .net object graph over the wire of course. Transferring .net object graphs works only in .net environment and it is not interoperable with other worlds. So as long as you are doing .net – .net you are fine.

The best option for this scenario is RO's Binary data type, a class derived from MemoryStream in RO.net version. I guess you see where I am going – I'll be doing manual (de)serialization to/from Binary.

Imagine we have a RO service method defined like this:

public Binary DoSomething(Binary args) { ... }

and in reality it should look like this:

public ReturnClass DoSomething(SomeClass args) { ... }

You will have to do some classic serialization:

public ReturnClass DoSomething(SomeClass args) 
{
  Binary binaryIn = new Binary();
  BinaryFormatter formatter = new BinaryFormatter();
  formatter.Serialize(binaryIn, data);
  binaryIn.Position = 0;
  Binary result = DoSomething(binaryIn);

and some classic deserialization:

  result.Position = 0;
  BinaryFormatter formatter = new BinaryFormatter();
  return (ReturnClass)formatter.Deserialize(result);
}

However, when you deal with many methods that require this exercise the task soon becomes annoying. That's why I've created ROHelper class that does much of the (de)serialization for you. With some help of generics here it is:

public class ROHelper
{
    public static T ConvertFromBinary<T>(Binary binary)
    {
        binary.Position = 0;
        BinaryFormatter formatter = new BinaryFormatter();
        return (T)formatter.Deserialize(binary);
    }

    public static Binary ConvertFrom<T>(T data)
    {
        Binary binary = new Binary();
        BinaryFormatter formatter = new BinaryFormatter();
        formatter.Serialize(binary, data);
        binary.Position = 0;
        return binary;
    }
}

and here is the DoSomething method rewritten:

public ReturnClass DoSomething(SomeClass args) 
{
  return ROHelper.ConvertFromBinary<ResultClass>(
    DoSomething(
        ROHelper.ConvertFrom(args)
    ));
}

Isn't this code much better than spaghetti code above? Also note, that method ConvertFrom<T> doesn't require explicit definition of type T as it is deduced from argument itself.

The only thing that remains to improve is code generation itself. Even with simpler code like this you have to write all those method wrappers. So, the next step is to build code wrapper generator. Next time, perhaps.

How can you strong sign an assembly using key located in key container (not in a file) from within Visual Studio 2005 (SP1)? You can’t. For whatever reason MS decided not to give us this option in the 2005 RTM timeframe (apparently they didn’t have time). Now, much later, they apparently still don’t have enough time to implement it.

Why would one bother? Because storing strong key in key container (which is protected by OS) is more secure. It is also easier to reference such strong key as you need only its name and not the entire file path.

At least there has been a workaround which still works.

WARNING: VB code!

Here is a very popular problem that many VB developers fail to see. Furthermore, it is hard to find once in the code. Can you spot it?

imports Microsoft.VisualBasic
imports System

public module MyModule
    sub Main
        dim a as integer = 0
        dim b as integer = CInt(iif(a=0, 100, SomeCalc(a)))
    end sub
    
    private function SomeCalc(a as integer) as integer
        if a = 0 then
            throw new ArgumentNullException("a")
        else
            return CInt(100 / a)
        end if
    end function
end module