We are often required to pass critical data to some or all of the calls to our service operations. Data such as user or security tokens, special parameters, time signatures, etc. It is not recommended to pass these kind of values as parameters of the calls, the best is to separate the business logic from the context data of our services.
Adding custom headers to the calls is in this case the best solution.
The whole operation is composed of four steps:

• Client
  • Add header to the outgoing context message
  • Call the operation
• Service
  • Extract header data
  • Execute operation and return result

The simplest way to add a custom header to a WCF call would be to manually attach it to each call’s OperationContext.

Inside the client, we assume we already added a reference to the service name, MyServiceRef. 

The header can be added to the call by overloading the constructor of the MyServiceRef.MyServiceClient in a custom class.

public class MyService : MyServiceClient
{
//Init service and attach custom header
public MyService(string customHeader) : base()
{
MessageHeader header
= MessageHeader.CreateHeader(
HeaderId.HeaderName,
HeaderId.HeaderNS,
customHeader
);
OperationContextScope scope =
new OperationContextScope(this.InnerChannel);
OperationContext.Current.OutgoingMessageHeaders.Add(header);
}
}

When calling asynchronously GetHeader() function of MyService asynchronously from the client application, it is critical to assign the event inside the using statement to keep the integrity of the call and therefore to correctly attach the custom header to the context, before the actual operation call.

//call service and attach the header
using (MyService client = new MyService(textBox1.Text))
{
client.GetHeaderCompleted +=
new EventHandler<MyServiceRef.GetHeaderCompletedEventArgs>
(client_GetHeaderCompleted); client.GetHeaderAsync();
}

Inside the WCF service, the extraction of the header from the current OperationContext can be done as following:

static string GetHeaderInfo()
{
System.ServiceModel.Channels.MessageHeaders headers =
OperationContext.Current.IncomingMessageHeaders;
return headers.GetHeader<string>(
HeaderId.HeaderName,
HeaderId.HeaderNS);
}

Headers are usually used to pass sensitive data, so to assure their integrity, I can think of a few things to recommend:

• if possible try to generate the content of the header inside the service (following a login function for example)
• try using at least a basic encryption system on the content of the header

  Source code for this post is included here.

Adrian

What is Silverlight?
If we follow the definition, Silverlight is “is a web application framework that provides functionalities similar to those in Adobe Flash, integrating multimedia, graphics, animations and interactivity into a single runtime environment.”

Running Silverlight out of the browser, just like a normal application was no longer a restriction, starting from Silverlight 3. But even locally installed, Silverlight application still runs in a sandbox, thus preventing the invocation of platform APIs.

Unfortunately, until now, there was no way to allow a Silverlight application to behave like a real application, and this is a limitation from the Silverlight’s .NET Framework which is a subset of the Windows Presentation Framework.

Silverlight Extender Project
Why until now? Because the Silverlight Extender Project was created especially as a way to extend Silverlight’s functionality, and to allow it, under certain circumstances, to behave as a standard windows application. Of course, this whole process falls under a special security model, which uses a combination of permission sets and deployment zones to determine the Silverlight application’s privileges.

What is the purpose of this project?
This project may look weird to some, they may ask – we have WPF, why shouldn’t we use it instead of an extender for Silverlight? Wouldn’t this break the whole security model Microsoft imagined for Silverlight, the whole idea of a Silverlight sandbox?

Well, for me the answer can be found in the development simplicity and portability.
I have many times asked myself the following question: if Silverlight framework is a subset of WPF framework, why is there no simple way to create common Sillverlight components to be used inside WPF applications? Why did they avoid to preview an interaction between the two technologies?

Security
The fact that we are extending the functionality and the rights of a Silverlight application, doesn’t mean that we will blindly expose the standard user to security risks.
To be more precise, an isolated sandbox will always exist. A certificate will be required to validate against the Silverlight Extender Framework. No full disk access or registry permissions will be given unless explicit permissions are validated by the user regarding each allowed operation performed by a certain Silverlight application. Also the ability to send messages to other applications using the Silverlight Extender will be based on special permissions. This is a vast subject and will be discussed in detail on the project’s page.

The project is currently in alpha stage, if you would like to be updated about the project, to see how it evolves, keep an eye on the Silverlight Extender Project page, or subscribe to my blog.
If you would like to contribute to this project, just drop me an e-mail with your expertise/skills on .NET/WPF/Silverlight and how do you think you could help.

Adrian