Jan Schepens

Never underestimate the power of parameter order

Jan Schepens — Mon, 29 Sep 2008 11:05:10 GMT

Recently, I ran into an interesting situation
the client caller of a WCF service method had adjusted his proxy class and for some reason the order of two parameters were switched.
So let's say I have a method with a boolean parameter and an integer parameter as in X(bool b, int i)
In this case the proxy was changed to X(int i, bool b)

Now this is where it gets interesting. There is no error whatsoever on execution of the method. When debugging, the method was entered and executed without any trouble. But the boolean did get it's default value false, even when sending a true.
But the amazing thing was that the int parameter retained value, instead of a default 0, what I would expect.

Conclusion: never underestimate the power of order of parameters

Any WCF experts willing to clear some things up on this matter, don't hesitate to mail me :)

Adding zip files in a jpg

Jan Schepens — Tue, 19 Aug 2008 11:51:14 GMT

I don't know how many people already know this, but I just stumbled upon this through another site and I just had to share :)

So I already did some experimenting about 2 years ago with hiding messages in an image file. But I had no idea it was
this easy to hide a zip in there as well :)

the way to do this just seems to be
1) create a new folder
2) place your jpg file and zip file in there
3) open a command prompt and navigate to your new folder
4) type COPY /B <picturename>.jpg + <zipname>.zip <resultpicture>.jpg

that will create the result picture in the same folder and if you change the extension of that picture back to .zip, you'll be
able to extract everything back from the original zip file.

I think that's fun :)

Easily retrieving message body AND context from BizTalk tracking database

Jan Schepens — Thu, 03 Apr 2008 12:01:41 GMT

I've been searching for a while now on a way to retrieve message body and context from BizTalk without having to use WMI,
simply because I didn't want to write my messages to file, read them back in, parse the context and then delete the generated
files again.

Interesting blog post I stumbled upon was this: View post

But this was not sufficient, because no one managed to get the FULL message context from this method. However, there is a very easy way to do this.

First of all, I defined two strings representing a property name, and a property namespace. They will be the out values for our method.
Now the Context object we get from the tracked message out of the BizTalk Operations dll, implements the Microsoft.BizTalk.Message.Interop.IBaseMessageContext interface. When you look closely at it's methods, you will see a "ReadAt" method. That's the one we need to use.
The Context object also contains a CountProperties variable, which doesn't need any further explanation I think.
So the next part is pretty straight-forward right?
Loop through the CountProperties values, use them as indexes, and call the ReadAt(index, name, namespace) method
for every loop passage, and hold the property value in another string variable.

                string sname = "";
                string snamespace = "";

                for (int i = 0; i < imsg.Context.CountProperties; i++)
                {
                    string value = imsg.Context.ReadAt(i, out sname, out snamespace).ToString();
                    Console.WriteLine(sname + " (" + snamespace + ") = " + value);
                }

And there you have it! Full message context!
Enjoy experimenting with this very cool way of getting body and context of a BizTalk message! IMHO, this is a much better
approach than the WMI way.

Processing custom WCF header values at server-side

Jan Schepens — Mon, 17 Mar 2008 15:41:14 GMT

Well since my previous post was about passing information from client to server in a WCF header, this post is about processing
the incoming header to retrieve the original username.

If you read my previous post, I used a class RequestAuth and ProcessAuth. This post will explain the ProcessAuth class.

This time I need to FETCH something from the message, so instead of implementing IClientMessageInspector, I need to implement the IDispatchMessageInspector interface,
together with the IEndpointBehavior interface again, and I need to inherit from BehaviorExtensionElement again, so I can add this
functionality to my endpoint behavior.

In the previous post, I explained that it can be convenient to override BehaviorType and CreateBehavior, so I'll do this again:
        public override Type BehaviorType
        {
            get { return typeof(ProcessAuth); }
        }

        protected override object CreateBehavior()
        {
            return new ProcessAuth();
        }

Also, to store the current user to send to the server, I'll hold a private field userName:
[System.Diagnostics.DebuggerBrowsable(System.Diagnostics.DebuggerBrowsableState.Never)]
private string userName;

Now, for the IDispatchMessageInspector implementation, it's fairly simple when you think about it. At client-side, I implemented the
BeforeSendRequest of the IClientMessageInspector interface. Now I am at server-side level, so I need to implement AfterReceiveRequest of
the IDispatchMessageInspector interface.

        public object AfterReceiveRequest(ref System.ServiceModel.Channels.Message request, System.ServiceModel.IClientChannel channel, System.ServiceModel.InstanceContext instanceContext)
        {
            sUser = request.Headers.GetHeader<string>("SomeName", "http://SomeNameSpace", "Anyone");
            return CheckSecurity();
        }

NOTE: I'm using the same name and namespace for the header as I did at client-side level. This is of course very logically that those two
need to be the same :) otherwise you would never get the right values.
At the end of the method I return CheckSecurity(). This is a boolean method which you can implement at your own needs, it just returns true
or false depending of the access-allowed level of the requesting user.

And that's it for the MessageInspector part! Of course, we also need to add this inspector to every incoming request. This is where theIEndpointBehavior interface comes in again. However, instead of implementing the ApplyClientBehavior method (client-side), we need
to implement the ApplyDispatchBehavior this time, for server-side.

        public void ApplyDispatchBehavior(ServiceEndpoint endpoint, EndpointDispatcher endpointDispatcher)
        {
            endpointDispatcher.DispatchRuntime.MessageInspectors.Add(this);
        }

THAT'S IT FOR THE SERVER SIDE!!!
Adding this to your server endpoints can be done in the same way I did it in the client configurations.

TO SUMMARIZE: Well, we actually did a lot of work in here with very little code writing. But in my opinion, this shows a nice feature of
customizing WCF.
With this example, you can use your own WCF headers to send some information to the server, and process it there. And not only that, but
you can do this completely automatically by using custom endpoint behaviors.

So that's it concerning my first blogpost :) hope you enjoyed, and feel free to give some feedback!

Automate passing valuable information in WCF headers

Jan Schepens — Mon, 17 Mar 2008 15:25:10 GMT

OK so this is my first blogpost (EVER) so I hope it'll be of value to some people.

This post is about passing through some information at the client to the server, and how to automate this using the WCF configuration.

Case study:
I was with a client, developing WCF services which are hosted on IIS. Since they already have a wide range of security settings stored in databases, it would be a shame to let go of those configurations and force a whole new security model on them instead of trying to integrate their configs into the services.
We have several end users surfing to an intranet site (which is our WCF client), while the site communicates with several servers running WCF services on IIS. The site runs under a simple network service so the Windows Authentication is guaranteed server-side.
But to ensure security for several users (not everyone is allowed to view the same information) we want to pass the current username to the WCF service, and perform a security check with the client configurations, before returning any results.

How do we do this? Well there are probably tons of solutions available, but the way that worked the easiest for me (and my client) is working with custom behaviors on the endpoints, where the username will be passed in a WCF header.

So we need two classes: one to add the header client-side, and one to process the username server-side. In my example, I call them RequestAuth and ProcessAuth. Let's start out with RequestAuth.

Since I want to add something to the message at the endpoint level, I'll need to implement the IClientMessageInspector interface, which is found in the System.ServiceModel.Dispatcher namespace, and the IEndpointBehavior interface, in the System.ServiceModel.Description namespace. BUT, since we are going to add this to a behavior, we need to inherit from the BehaviorExtensionElement class, in the System.ServiceModel.Configuration namespace.

Now before we start implementing, bare in mind that it might come in handy to override the BehaviorType property of BehaviorExtensionElement, as well as the CreateBehavior() method. This is done easily by doing:
    public override Type BehaviorType
    {
            get { return typeof(RequestAuth); }
    }

    protected override object CreateBehavior()
    {
            return new RequestAuth();
    }

Also, to store the current user to send to the server, I'll hold a property UserName:
[System.Diagnostics.DebuggerBrowsable(System.Diagnostics.DebuggerBrowsableState.Never)]
private string userName;

    public string UserName
    {
            get { return userName; }
            set { userName = value; }
    }

Note: by using the System.Diagnostics.DebuggerBrowsable attribute and setting it to never, no client will ever get to see the private fields in your code. Not only is this safer, but it also gives a better debugger view when debugging.
Now, while it is not necessary anymore in .NET 3.5 to link a property to a private field, this example was written in .NET 2.0, so if you are redoing this in 3.5 you won't need the username field.

On to the implementations then! At first, I have to implement the IClientMessageInspector members.
Keeping in mind that I am SENDING something to the server, I only need to implement the BeforeSendRequest method.

So we need to make a MessageHeader object of string to send the username. After that, I try to retrieve the current logged on user.
In here I needed to make a difference between web applications and desktop applications. But if you are certain that you will ALWAYS
run in one environment (web or desktop) you can drop the check and keep the right username
Now, before I did the actual implementation, I keep a name and a namespace for my header in two private fields, so I can easily find
them back server side.
    [System.Diagnostics.DebuggerBrowsable(System.Diagnostics.DebuggerBrowsableState.Never)]
        private string hName = "SomeName"; //use your own name for the header in here
        [System.Diagnostics.DebuggerBrowsable(System.Diagnostics.DebuggerBrowsableState.Never)]
        private string hNameSpace = "http://SomeNameSpace"; //use own namespace here

        public object BeforeSendRequest(ref System.ServiceModel.Channels.Message request, System.ServiceModel.IClientChannel channel)
        {
            MessageHeader<string> header = new MessageHeader<string>();
            header.Actor = "Anyone";

            //Keep the difference between web environments and desktop environments
            if (System.Web.Hosting.HostingEnvironment.IsHosted)
            {
                if (OperationContext.Current != null)
                    UserName = OperationContext.Current.ServiceSecurityContext.WindowsIdentity.Name;
                else
                {
                    if(System.Web.HttpContext.Current != null)
                        UserName = System.Web.HttpContext.Current.User.Identity.Name;
                }
            }
            else
                UserName = System.Threading.Thread.CurrentPrincipal.Identity.Name;

            //Add the username to the header
            header.Content = UserName;

            //Creating an untyped header to add to the WCF context
            System.ServiceModel.Channels.MessageHeader unTypedHeader = header.GetUntypedHeader(hName, hNameSpace);

            //Add the header to the current request
            request.Headers.Add(unTypedHeader);

            return null;
        }

So the previous code snippet will add a string containing the username to the WCF request. But to do this for every request, we still
need to add the MessageInspector we just implemented to the behavior. So on to the implementation of the IEndpointBehavior interface!
Well there's nothing much to it in this part, but to use the current clientbehavior and add the inspector:
        public void ApplyClientBehavior(ServiceEndpoint endpoint, ClientRuntime clientRuntime)
        {
            clientRuntime.MessageInspectors.Add(this);
        }
NOTE: I use <this> as parameter, because the class we are working in IS a message inspector, thanks to the IClientMessageInspector interface
we implemented.

THAT'S IT FOR THE CLIENT SIDE!!! If you build this in an assembly and sign it, you will be able to add this in your WCF config file.
HOW? Simple: Open your WCF config file with the WCF Config Editor tool (SvcConfig.exe). Under the "Advanced" node, within "Extensions", you have
a node "behavior element extensions". That's where you click New, give your extension a name, and browse to your newly created assembly, and select
the correct behavior element to add (if you have multiple in one assembly). In this case, you need to select the RequestAuth item.
Once this is done, you can navigate to your Endpoint Behaviors, and in your behavior, if you click Add, you will see the new extension in the
list of available extensions. From now on, every service that uses this endpoint behavior will add the new username header to every outgoing request
it makes.