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!