Implementing CORS support in WCF

Article
05/14/2012

The code for this post can be downloaded from the MSDN Code Gallery.

A pair of popular posts which I did a couple months back was to show how one can implement CORS (Cross-Origin Resource Sharing) in the net ASP.NET Web API framework. This week I found a couple of posts in the WCF forums from a user who wanted to make cross-domain calls to a WCF REST service. They were trying to use JSONP, but it didn’t work because the request needed to be made using non-GET verbs. So let’s try to implement the same support which we did fairly easily in the new API in WCF.

Cross-domain calls

A quick recap about the problem: in order to prevent malicious sites to “stealing” cookies from good sites and using them to get access to protected resources (imagine going to a bad site, and scripts in that site accessing your online bank and transferring your money elsewhere), browsers block by default AJAX requests going to domains other than the one where the HTML page originated. This is good for security purposes, but it blocks some valid scenarios, such as mash-up applications which gather data from many sources. There are some alternatives to make this scenario work, including JSONP (JSON with Padding), or using a separate “proxy” service on the same domain as the page to route the requests to the destination server. But those approaches have limitations: JSONP only works for GET requests (since it uses the <script> element in the HTML DOM, and proxy services need to be deployed on many places and add another level of indirection (and point of failure) to the system.

CORS (Cross-Origin Resource Sharing) is a new specification which defines a set of headers which can be exchanged between the client and the server which allow the server to relax the cross-domain restrictions for all HTTP verbs, not only GET. Also, since CORS is implemented in the same XmlHttpRequest as “normal” AJAX calls (in Firefox 3.5 and above, Safari 4 and above, Chrome 3 and above, IE 10 and above – in IE8/9, the code needs to use the XDomainRequest object instead), the JavaScript code doesn’t need to worry about “un-padding” responses or adding dummy functions. The error handling is also improved with CORS, since services can use the full range of the HTTP response codes (instead of 200, which is required by JSONP) and the code also has access to the full response instead of only its body.

CORS operation

There are two types of requests in the CORS world, “normal” requests and preflight requests. Normal requests are the requests which the page would normally make to the service, with an additional header, “Origin”, which indicates the origin and the service can determine whether to allow cross-domain calls from that origin or not (via the “Access-Control-Allow-Origin” response header). “Safe” requests (GET and HEAD) only use that extra headers to work. The browser will add the Origin header to requests going to domains other than the one where the page originated, and if the service doesn’t allow that domain, then the call will fail.

“Unsafe” requests, such as POST, PUT or DELETE, can’t be done the same way. If the service isn’t CORS-aware, it would ignore the “Origin” header and accept the request, with possible side effects (e.g., deleting a record), and at the time the client gets the response, the browser could still “fail” the request, but the damage has already been done. What the browser does in those cases is to first send a preflight request, which is a HTTP OPTIONS request asking for permission to send the actual request. If the service answers that request allowing the call, only then the browser will send the user request to the service.

CORS in WCF

So let’s start with the “normal” requests. That’s actually fairly simple to implement – we can use an inspector to check the “Origin” header in the requests, and if it’s present (and we want to allow the cross-domain request) on the reply we add the “Access-Control-Allow-Origin” header. As usual, we’ll start with a simple example, and go from there. And to make the comparison between WCF and the version I wrote in ASP.NET Web API easier, let’s use the exact same contract as that one.

[ServiceContract]
public interface IValues
{
[WebGet(UriTemplate = "values", ResponseFormat = WebMessageFormat.Json)]
List<string> GetValues();
[WebGet(UriTemplate = "values/{id}", ResponseFormat = WebMessageFormat.Json)]
string GetValue(string id);
[WebInvoke(UriTemplate = "/values", Method = "POST", ResponseFormat = WebMessageFormat.Json)]
void AddValue(string value);
[WebInvoke(UriTemplate = "/values/{id}", Method = "DELETE", ResponseFormat = WebMessageFormat.Json)]
void DeleteValue(string id);
[WebInvoke(UriTemplate = "/values/{id}", Method = "PUT", ResponseFormat = WebMessageFormat.Json)]
string UpdateValue(string id, string value);
}

The implementation is exactly the same as in the Web API one, so I’ll leave it out. Now, we need one “tagging” attribute to indicate whether an operation can be called via cross-domain calls or not. We can use an empty operation behavior attribute, which will be easily accessible via the operation description later.

public class CorsEnabledAttribute : Attribute, IOperationBehavior
{
public void AddBindingParameters(OperationDescription operationDescription, BindingParameterCollection bindingParameters)
{
}
public void ApplyClientBehavior(OperationDescription operationDescription, ClientOperation clientOperation)
{
}
public void ApplyDispatchBehavior(OperationDescription operationDescription, DispatchOperation dispatchOperation)
{
}
public void Validate(OperationDescription operationDescription)
{
}
}

And by having the CorsEnabled attribute as a IOperationBehavior, it allows us to filter through he operations for which we should implement the CORS handshake in our endpoint behavior.

class EnableCorsEndpointBehavior : IEndpointBehavior
{
public void AddBindingParameters(ServiceEndpoint endpoint, BindingParameterCollection bindingParameters)
{
}
public void ApplyClientBehavior(ServiceEndpoint endpoint, ClientRuntime clientRuntime)
{
}
public void ApplyDispatchBehavior(ServiceEndpoint endpoint, EndpointDispatcher endpointDispatcher)
{
List<OperationDescription> corsEnabledOperations = endpoint.Contract.Operations
.Where(o => o.Behaviors.Find<CorsEnabledAttribute>() != null)
.ToList();
endpointDispatcher.DispatchRuntime.MessageInspectors.Add(new CorsEnabledMessageInspector(corsEnabledOperations));
}
public void Validate(ServiceEndpoint endpoint)
{
}
}

The inspector is divided in two parts: incoming requests and the verification whether the “Origin” header was sent and whether the operation for where the request is directed is one of those which are CORS-enabled. The first information we get via the HttpRequestMessageProperty property. The second one we could look at the request URI, but since the inspector is executed after the operation selector, that information is already available in the message properties via the WebHttpDispatchOperationSelector.HttpOperationNamePropertyName key. If those two conditions are met, then we return the value of the Origin header, which will be passed to the BeforeSendReply method of the inspector.

The second part, for the response, starts by looking at the correlation state returned by the AfterReceiveRequest method. If there is something, then the request had an Origin header, and we’ll use the HttpResponseMessageProperty on the reply message to send back the Access-Control-Allow-Origin method.

class CorsEnabledMessageInspector : IDispatchMessageInspector
{
private List<string> corsEnabledOperationNames;
public CorsEnabledMessageInspector(List<OperationDescription> corsEnabledOperations)
{
this.corsEnabledOperationNames = corsEnabledOperations.Select(o => o.Name).ToList();
}
public object AfterReceiveRequest(ref Message request, IClientChannel channel, InstanceContext instanceContext)
{
HttpRequestMessageProperty httpProp = (HttpRequestMessageProperty)request.Properties[HttpRequestMessageProperty.Name];
object operationName;
request.Properties.TryGetValue(WebHttpDispatchOperationSelector.HttpOperationNamePropertyName, out operationName);
if (httpProp != null && operationName != null && this.corsEnabledOperationNames.Contains((string)operationName))
{
string origin = httpProp.Headers[CorsConstants.Origin];
if (origin != null)
{
return origin;
}
}
return null;
}
public void BeforeSendReply(ref Message reply, object correlationState)
{
string origin = correlationState as string;
if (origin != null)
{
HttpResponseMessageProperty httpProp = null;
if (reply.Properties.ContainsKey(HttpResponseMessageProperty.Name))
{
httpProp = (HttpResponseMessageProperty)reply.Properties[HttpResponseMessageProperty.Name];
}
else
{
httpProp = new HttpResponseMessageProperty();
reply.Properties.Add(HttpResponseMessageProperty.Name, httpProp);
}
httpProp.Headers.Add(CorsConstants.AccessControlAllowOrigin, origin);
}
}
}

And now, by decorating the GET operations with [CorsEnabled] and adding the EnableCorsEndpointBehavior to the endpoint, those operations can now be called via cross-domain.

Implementing preflight requests

The first part was easy. For the second part, we need to intercept the requests with the OPTIONS verb, and return the response immediately, without going to the operation. And that’s probably one of the biggest features missing in the WCF extensions – the ability to bypass the rest of the WCF pipeline at a given point. The first option is to use a custom reply channel (which, with anything in the channel layer, is really hard to write). The other option is to use a custom operation invoker which can bypass the actual operation. But the invoker by itself doesn’t work – on the invoker call you don’t have a reference to either the incoming request (to look for CORS headers) or the outgoing response (to set the response headers). Also, in order for the invoker to be called for OPTIONS requests (instead of the actual request), we needed to also have an operation selector which will map requests for OPTIONS verb to the actual operation. And it would also need some way to not map multiple operations which have the same URI template (but different verbs) to different operations, since OPTIONS will be the common ground there. And we’d also need to change the formatter so that the response for the OPTIONS request would be an empty response instead of the actual result of the operation… In short, not simple at all.

Another option, which I got the idea from the post about how to add dynamic operations from Zufilqar’s blog, is to not change the existing operations, but instead add new ones to handle the OPTIONS requests. Since I always try to avoid channels programming whenever possible, this seemed the best option given all the problems of using a custom invoker for the existing operations. Those operations actually need a custom invoker, but by making them operations with untyped messages (Message in, Message out), we don’t need a custom formatter, and we can access to the HTTP headers via the message properties as well.

To make this scenario simpler to use, let’s create a custom service host (and service host factory) to wrap the logic for creating the new operations. The service host will use as the contract type either the service type itself (if it is decorated with ServiceContractAttribute), or one interface the service type implements (and the interface is decorated with ServiceContractAttribute). More complex logic can be added if needed, but for this scenario, this is enough.

When the service host is being opened, we’ll add the single endpoint, find all the operations which are decorated with the CorsEnabled attribute, and for those, add a corresponding operation which deals with the preflight requests.

class CorsEnabledServiceHostFactory : ServiceHostFactory
{
protected override ServiceHost CreateServiceHost(Type serviceType, Uri[] baseAddresses)
{
return new CorsEnabledServiceHost(serviceType, baseAddresses);
}
}
class CorsEnabledServiceHost : ServiceHost
{
Type contractType;
public CorsEnabledServiceHost(Type serviceType, Uri[] baseAddresses)
: base(serviceType, baseAddresses)
{
this.contractType = GetContractType(serviceType);
}
protected override void OnOpening()
{
ServiceEndpoint endpoint = this.AddServiceEndpoint(this.contractType, new WebHttpBinding(), "");
List<OperationDescription> corsEnabledOperations = endpoint.Contract.Operations
.Where(o => o.Behaviors.Find<CorsEnabledAttribute>() != null)
.ToList();
AddPreflightOperationSelectors(endpoint, corsEnabledOperations);
endpoint.Behaviors.Add(new WebHttpBehavior());
endpoint.Behaviors.Add(new EnableCorsEndpointBehavior());
base.OnOpening();
}
private Type GetContractType(Type serviceType)
{
if (HasServiceContract(serviceType))
{
return serviceType;
}
Type[] possibleContractTypes = serviceType.GetInterfaces()
.Where(i => HasServiceContract(i))
.ToArray();
switch (possibleContractTypes.Length)
{
case 0:
throw new InvalidOperationException("Service type " + serviceType.FullName + " does not implement any interface decorated with the ServiceContractAttribute.");
case 1:
return possibleContractTypes[0];
default:
throw new InvalidOperationException("Service type " + serviceType.FullName + " implements multiple interfaces decorated with the ServiceContractAttribute, not supported by this factory.");
}
}
private static bool HasServiceContract(Type type)
{
return Attribute.IsDefined(type, typeof(ServiceContractAttribute), false);
}
}

In order to add the preflight operations, we first iterate over all the CORS-enabled operations which need to respond to the preflight request (GET requests don’t need those). For those operations, we first get the URI template for the operation, and normalize it (remove query string parameters, and remove the parameter lists replacing them with wildcards) so that two operations with similar URI templates (e.g., [WebInvoke(Method = “POST”, UriTemplate = “/products/{param1}?x={param2}”)] and [WebInvoke(Method = “DELETE”, UriTemplate = “/products/{id}”)]) will have only one new operation for the “/products/*” URI. If there is already an OPTIONS operation for the normalized URI we’ll add HTTP verb to it, otherwise we’ll create a new operation to handle the OPTIONS request.

private void AddPreflightOperations(ServiceEndpoint endpoint, List<OperationDescription> corsOperations)
{
Dictionary<string, PreflightOperationBehavior> uriTemplates = new Dictionary<string, PreflightOperationBehavior>(StringComparer.OrdinalIgnoreCase);
foreach (var operation in corsOperations)
{
if (operation.Behaviors.Find<WebGetAttribute>() != null || operation.IsOneWay)
{
// no need to add preflight operation for GET requests, no support for 1-way messages
continue;
}
string originalUriTemplate;
WebInvokeAttribute originalWia = operation.Behaviors.Find<WebInvokeAttribute>();
if (originalWia != null && originalWia.UriTemplate != null)
{
originalUriTemplate = NormalizeTemplate(originalWia.UriTemplate);
}
else
{
originalUriTemplate = operation.Name;
}
string originalMethod = originalWia != null && originalWia.Method != null ? originalWia.Method : "POST";
if (uriTemplates.ContainsKey(originalUriTemplate))
{
// there is already an OPTIONS operation for this URI, we can reuse it
PreflightOperationBehavior operationBehavior = uriTemplates[originalUriTemplate];
operationBehavior.AddAllowedMethod(originalMethod);
}
else
{
ContractDescription contract = operation.DeclaringContract;
OperationDescription preflightOperation;
PreflightOperationBehavior preflightOperationBehavior;
CreatePreflightOperation(operation, originalUriTemplate, originalMethod, contract, out preflightOperation, out preflightOperationBehavior);
uriTemplates.Add(originalUriTemplate, preflightOperationBehavior);
contract.Operations.Add(preflightOperation);
}
}
}

Creating the preflight operation means creating a new operation description for the contract, adding two messages to it: an input message with a single body part of type Message, and an output message with a return value of the same type. We then use the same URI template as the original operation, and add a WebInvokeAttribute to the operation. We then add a DataContractSerializerOperationBehavior to the operation description, since it will give us a formatter which understands the (Message in, Message out) pattern. Finally, we add our custom operation behavior, which we’ll use to implement the operation invoker which will ultimately deal with the preflight request

private static void CreatePreflightOperation(OperationDescription operation, string originalUriTemplate, string originalMethod, ContractDescription contract, out OperationDescription preflightOperation, out PreflightOperationBehavior preflightOperationBehavior)
{
preflightOperation = new OperationDescription(operation.Name + CorsConstants.PreflightSuffix, contract);
MessageDescription inputMessage = new MessageDescription(operation.Messages[0].Action + CorsConstants.PreflightSuffix, MessageDirection.Input);
inputMessage.Body.Parts.Add(new MessagePartDescription("input", contract.Namespace) { Index = 0, Type = typeof(Message) });
preflightOperation.Messages.Add(inputMessage);
MessageDescription outputMessage = new MessageDescription(operation.Messages[1].Action + CorsConstants.PreflightSuffix, MessageDirection.Output);
outputMessage.Body.ReturnValue = new MessagePartDescription(preflightOperation.Name + "Return", contract.Namespace) { Type = typeof(Message) };
preflightOperation.Messages.Add(outputMessage);
WebInvokeAttribute wia = new WebInvokeAttribute();
wia.UriTemplate = originalUriTemplate;
wia.Method = "OPTIONS";
preflightOperation.Behaviors.Add(wia);
preflightOperation.Behaviors.Add(new DataContractSerializerOperationBehavior(preflightOperation));
preflightOperationBehavior = new PreflightOperationBehavior(preflightOperation);
preflightOperationBehavior.AddAllowedMethod(originalMethod);
preflightOperation.Behaviors.Add(preflightOperationBehavior);
}

Finally, the custom invoker. The implementation of the IOperationInvoker interface is fairly trivial: allocate 1 input, only work with synchronous operations. The Invoke calls the operation to handle the preflight request: take the incoming message HttpRequestMessageProperty property, get any CORS-specific headers, then create an empty reply message, and add to it a HttpResponseMessageProperty property with the appropriate headers.

class PreflightOperationInvoker : IOperationInvoker
{
private string replyAction;
List<string> allowedHttpMethods;
public PreflightOperationInvoker(string replyAction, List<string> allowedHttpMethods)
{
this.replyAction = replyAction;
this.allowedHttpMethods = allowedHttpMethods;
}
public object[] AllocateInputs()
{
return new object[1];
}
public object Invoke(object instance, object[] inputs, out object[] outputs)
{
Message input = (Message)inputs[0];
outputs = null;
return HandlePreflight(input);
}
public IAsyncResult InvokeBegin(object instance, object[] inputs, AsyncCallback callback, object state)
{
throw new NotSupportedException("Only synchronous invocation");
}
public object InvokeEnd(object instance, out object[] outputs, IAsyncResult result)
{
throw new NotSupportedException("Only synchronous invocation");
}
public bool IsSynchronous
{
get { return true; }
}
Message HandlePreflight(Message input)
{
HttpRequestMessageProperty httpRequest = (HttpRequestMessageProperty)input.Properties[HttpRequestMessageProperty.Name];
string origin = httpRequest.Headers[CorsConstants.Origin];
string requestMethod = httpRequest.Headers[CorsConstants.AccessControlRequestMethod];
string requestHeaders = httpRequest.Headers[CorsConstants.AccessControlRequestHeaders];
Message reply = Message.CreateMessage(MessageVersion.None, replyAction);
HttpResponseMessageProperty httpResponse = new HttpResponseMessageProperty();
reply.Properties.Add(HttpResponseMessageProperty.Name, httpResponse);
httpResponse.SuppressEntityBody = true;
httpResponse.StatusCode = HttpStatusCode.OK;
if (origin != null)
{
httpResponse.Headers.Add(CorsConstants.AccessControlAllowOrigin, origin);
}
if (requestMethod != null && this.allowedHttpMethods.Contains(requestMethod))
{
httpResponse.Headers.Add(CorsConstants.AccessControlAllowMethods, string.Join(",", this.allowedHttpMethods));
}
if (requestHeaders != null)
{
httpResponse.Headers.Add(CorsConstants.AccessControlAllowHeaders, requestHeaders);
}
return reply;
}
}

That’s it. We can now use the custom service host factory to webhost our service, and use a page in another web service to call our service – as long as the browser supports CORS (which means the latest Chrome and Firefox, and IE 10 and above). You can find the code for a sample page at the sample in the code gallery.

Final thoughts: WCF vs. ASP.NET Web APIs

This is a good example to compare the extensibility between WCF and the ASP.NET Web APIs. The implementation of this scenario took a lot more code (and a non-negligible number of extension points) to be done in WCF compared with a similar solution in Web API. This is a specific HTTP scenario, and for those cases, Web APIs will likely be easier. But what I tried to do (and did) was to show that it can be done in WCF, so if you have an investment in that technology, you don’t need to hurry to make the change (if you’re starting a new project, and the focus of the project is HTTP only and the Web, then Web API would be a logical choice).

[Code in this post]